idnits 2.17.1 draft-ietf-pim-pop-count-07.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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors 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 (October 4, 2012) is 4221 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) == Outdated reference: A later version (-18) exists of draft-ietf-mboned-auto-multicast-14 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Dino Farinacci 3 Internet-Draft Greg Shepherd 4 Intended status: Experimental Stig Venaas 5 Expires: April 7, 2013 Cisco Systems 6 Yiqun Cai 7 Microsoft 8 October 4, 2012 10 Population Count Extensions to PIM 11 draft-ietf-pim-pop-count-07.txt 13 Abstract 15 This specification defines a method for providing multicast 16 distribution-tree accounting data. Simple extensions to the PIM 17 protocol allow a rough approximation of tree-based data in a scalable 18 fashion. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on April 7, 2013. 37 Copyright Notice 39 Copyright (c) 2012 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 4 56 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 57 2. Pop-Count-Supported Hello Option . . . . . . . . . . . . . . . 5 58 3. New Pop-Count Join Attribute Format . . . . . . . . . . . . . 6 59 3.1. Options . . . . . . . . . . . . . . . . . . . . . . . . . 9 60 3.1.1. Link Speed Encoding . . . . . . . . . . . . . . . . . 10 61 3.2. Example message layouts . . . . . . . . . . . . . . . . . 11 62 4. How to use Pop-Count Encoding . . . . . . . . . . . . . . . . 13 63 5. Implementation Approaches . . . . . . . . . . . . . . . . . . 14 64 6. Caveats . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 65 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 66 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 67 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 68 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 69 10.1. Normative References . . . . . . . . . . . . . . . . . . . 19 70 10.2. Informative References . . . . . . . . . . . . . . . . . . 19 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 73 1. Introduction 75 This document specifies a mechanism to convey accounting information 76 using the PIM protocol [RFC4601] [RFC5015]. Putting the mechanism in 77 PIM allows efficient distribution and maintenance of such accounting 78 information. Previous mechanisms require data to be correlated from 79 multiple router sources. 81 This mechanism allows a single router to be queried to obtain 82 accounting and statistic information for a multicast distribution 83 tree as a whole or any distribution sub-tree downstream from a 84 queried router. The amount of information is fixed and does not 85 increase as multicast membership, tree diameter, or branching 86 increase. 88 The sort of accounting data this specification provides, on a per 89 multicast route basis, are: 91 1. The number of branches in a distribution tree. 93 2. The membership type of the distribution tree, that is Source- 94 Specific Multicast (SSM) or Any-Source Multicast (ASM). 96 3. Routing domain and time zone boundary information. 98 4. On-tree node and tree diameter counters. 100 5. Effective MTU and bandwidth. 102 This document defines a new PIM Join Attribute type [RFC5384] to the 103 Join/Prune message as well as a new Hello option. The mechanism is 104 applicable to IPv4 and IPv6 multicast. 106 This is a new extension to PIM, and it is not completely understood 107 what impact collecting information using PIM would have on the 108 operation of PIM. This is an entirely new concept. Many PIM 109 features (including the core protocols) were first introduced as 110 Experimental RFCs, and it seems appropriate to advance this work as 111 Experimental. Reports of implementation and deployment across whole 112 distribution trees or within sub-trees (see Section 6) will enable an 113 assessment of the desirability and stability of this specification. 114 The PIM working group will then consider whether to move this work to 115 the Standards Track. 117 This document does not specify how an administrator or user can 118 access this information. It is expected that an implementation may 119 have a command line interface or other ways of requesting and 120 displaying this information. As this is currently an Experimental 121 document, defining a MIB module has not been considered. If the PIM 122 working group finds that this should move on to Standards Track, a 123 MIB module should be considered. 125 1.1. Requirements Notation 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 129 document are to be interpreted as described in [RFC2119]. 131 1.2. Terminology 133 This section defines the terms used in this document. 135 Multicast Route: A (S,G) or (*,G) entry regardless if the route is 136 in ASM, SSM, or Bidir mode of operation. 138 Stub Link: A link with members joined to the group via IGMP or 139 Multicast Listener Discovery (MLD) 141 Transit Link: A link put in the oif-list (outgoing interface list) 142 for a multicast route because it was joined by PIM routers. 144 Note that a link can be both a Stub Link and a Transit Link at the 145 same time. 147 2. Pop-Count-Supported Hello Option 149 A PIM router indicates that it supports the mechanism specified in 150 this document by including the Pop-Count-Supported Hello option in 151 its PIM Hello message. Note that it also needs to include the Join- 152 Attribute Hello option as specified in [RFC5384]. The format of the 153 Pop-Count-Supported Hello option is defined to be: 155 0 1 2 3 156 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | OptionType | OptionLength | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 OptionType = TBD1, OptionLength = 0. Note that there is no option 162 value included. In order to allow future updates of this 163 specification that may include an option value, implementations of 164 this document MUST accept and process this option also if the length 165 is non-zero. Implementations of this specification MUST accept and 166 process the option ignoring any option value that may be included. 168 3. New Pop-Count Join Attribute Format 170 When a PIM router supports this mechanism and has determined from a 171 received Hello, that the neighbor supports this mechanism, and also 172 that all the neighbors on the interface support the use of join 173 attributes, it will send Join/Prune messages that MAY include a Pop- 174 Count Join Attribute. The mechanism to process a PIM Join Attribute 175 is described in [RFC5384]. The format of the new attribute is 176 specified in the following. 178 0 1 2 3 179 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 |F|E| Attr Type | Length | Effective MTU | 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 | Flags | Options Bitmap | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | Options | 186 . . . 187 . . . 188 . . . 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 The above format is used only for entries in the join-list section of 192 the Join/Prune message. 194 F bit: 0 Non-Transitive Attribute. 196 E bit: As specified by [RFC5384]. 198 Attr Type: TBD2. 200 Length: The minimum length is 6. 202 Effective MTU: This contains the minimum MTU for any link in the 203 oif-list. The sender of Join/Prune message takes the minimum 204 value for the MTU (in bytes) from each link in the oif-list. If 205 this value is less than the value stored for the multicast route 206 (the one received from downstream joiners) then the value should 207 be reset and sent in Join/Prune message. Otherwise, the value 208 should remain unchanged. 210 This provides one to obtain the MTU supported by multicast 211 distribution tree when examined at the first-hop router(s) or for 212 sub-tree for any router on the distribution tree. 214 Flags: The flags field has the following format: 216 0 1 217 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | Unalloc/Reserved |P|a|t|A|S| 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 Unallocated/Reserved Flags: The flags which are currently not 223 defined. If a new flag is defined and used by a new 224 implementation, an old implementation should preserve the bit 225 settings. This means that a router MUST preserve the settings 226 of all Unallocated/Reserved Flags in PIM Join messages received 227 from downstream routers in any PIM Join sent upstream. 229 S flag: If an IGMPv3 or MLDv2 report with an INCLUDE Mode group 230 record was received on any oif-list entry or the bit was set 231 from any PIM Join message. This bit should only be cleared 232 when the above becomes untrue. 234 A flag: If an IGMPv3 or MLDv2 report with an EXCLUDE Mode group 235 record, or an IGMPv1, IGMPv2, or MLDv1 report, was received on 236 any oif-list entry or the bit was set from any PIM Join 237 message. This bit should only be cleared when the above 238 becomes untrue. 240 A combination of settings for these bits indicate: 242 A-flag S-flag Description 243 ------ ------ -------------------------------------- 244 0 0 There are no members for the group 245 ('Stub Oif-List Count' is 0) 246 0 1 All group members are using SSM 247 1 0 All group members are using ASM 248 1 1 A mixture of SSM and ASM group members 250 t flag: If there are any tunnels on the distribution tree. If a 251 tunnel is in the oif-list, a router should set this bit in its 252 Join/Prune messages. Otherwise, it propagates the bit setting 253 from downstream joiners. 255 a flag: If there are any auto-tunnels on the distribution tree. 256 If an auto-tunnel is in the oif-list, a router should set this 257 bit in its Join/Prune messages. Otherwise, it propagates the 258 bit setting from downstream joiners. An example of an auto- 259 tunnel is an tunnel setup by the AMT 260 [I-D.ietf-mboned-auto-multicast] protocol. 262 P flag: This flag is set by a router if all downstream routers 263 support this specification. That is, they are all PIM pop- 264 count capable. If a downstream router does not support this 265 specification it MUST be cleared. This allows one to tell if 266 the entire sub-tree is completely accounting capable. 268 Options Bitmap: This is a bitmap that shows which options are 269 present. The format of the bitmap is as follows: 271 0 1 272 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 |T|s|m|M|d|n|D|z| Unalloc/Rsrvd | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 Each one of the bits T, s, m, M, d, n, D and z is associated with 278 one option, where the option is included if and only if the 279 respective bit is set. Included options MUST be in the same order 280 as these bits are listed. The bits denote the following options: 282 bit Option 283 ----- ------------------------ 284 T Transit Oif-List Count 285 s Stub Oif-List Count 286 m Minimum Speed Link 287 M Maximum Speed Link 288 d Domain Count 289 n Node Count 290 D Diameter Count 291 z TZ Count 293 See Section 3.1 for details on the different options. The 294 unallocated bits are reserved. Any unknown bits MUST be set to 0 295 when a message is sent, and treated as 0 (ignored) when received. 296 This means that unknown options which are denoted by unknown bits 297 are ignored. 299 By using this bitmap we can specify at most 16 options. If there 300 becomes a need for more than 16 options, one can define a new 301 option that contains a bitmap, which can then be used to specify 302 which further options are present. The last bit in the current 303 bitmap could be used for that option. The exact definition of 304 this is however left for future documents. 306 Options: This field contains options. Which options are present 307 are determined by the flag bits. As new flags and options may be 308 defined in the future, any unknown/reserved flags MUST be ignored, 309 and any additional trailing options MUST be ignored. See 310 Section 3.1 for details on the options defined in this document. 312 3.1. Options 314 There are several options defined in this document. For each option, 315 there is also a related flag that shows whether the option is 316 present. See the Options Bitmap above for a list of the options and 317 their respective bits. Each option has a fixed size. Note that 318 there is no alignment requirements for the options, so an 319 implementation cannot assume they are aligned. 321 Transit Oif-List Count: This is filled in by a router sending a 322 Join/Prune message indicating the number of transit links on the 323 multicast distribution tree. The value is the number of oifs 324 (outgoing interfaces) for the multicast route that have been 325 joined by PIM plus the sum of the values advertised by each of the 326 downstream PIM routers that have joined on this oif. Length 4 327 octets. 329 Stub Oif-List Count: This is filled in by a router sending a Join/ 330 Prune message indicating the number of stub links (links where 331 there are host members) on the multicast distribution tree. The 332 value is the number of of oifs for the multicast route that have 333 been joined by IGMP or MLD plus the sum of the values advertised 334 by each of the downstream PIM routers that have joined on this 335 oif. Length 4 octets. 337 Minimum Speed Link: This contains the minimum bandwidth rate for 338 any link in the oif-list and is encoded as specified in 339 Section 3.1.1. The sender of Join/Prune message takes the minimum 340 value for each link in the oif-list for the multicast route. If 341 this value is less than the value stored for the multicast route 342 (the smallest value received from downstream joiners) then the 343 value should be reset and sent in Join/Prune message. Otherwise, 344 the value should remain unchanged. This together with the Maximum 345 Speed Link option provides a way to obtain the lowest and highest 346 speed link for the multicast distribution tree. Length 2 octets. 348 Maximum Speed Link: This contains the maximum bandwidth rate for 349 any link in the oif-list and is encoded as specified in 350 Section 3.1.1. The sender of Join/Prune message takes the maximum 351 value for each link in the oif-list for the multicast route. If 352 this value is greater than the value stored for the multicast 353 route (the largest value received from downstream joiners) then 354 the value should be reset and sent in Join/Prune message. 355 Otherwise, the value should remain unchanged. This together with 356 the Minimum Speed Link option provides a way to obtain the lowest 357 and highest speed link for the multicast distribution tree. 358 Length 2 octets. 360 Domain Count: This indicates the number of routing domains the 361 distribution tree traverses. A router should increment this value 362 if it is sending a Join/Prune message over a link which traverses 363 a domain boundary. For this to work, an implementation needs a 364 way of knowing that a neighbor or an interface is in a different 365 domain. There is no standard way of doing this. Length 1 octet. 367 Node Count: This indicates the number of routers on the 368 distribution tree. Each router will sum up all the Node Counts 369 from all joiners on all oifs and increment by 1 before including 370 this value in the Join/Prune message. Length 1 octet. 372 Diameter Count: This indicates the longest length of any given 373 branch of the tree in router hops. Each router that sends a Join 374 increments the max value received by all downstream joiners by 1. 375 Length 1 octet. 377 TZ Count: This indicates the number of timezones the distribution 378 tree traverses. A router should increment this value if it is 379 sending a Join/Prune message over a link which traverses a time 380 zone. This can be a configured link attribute or use other means 381 to determine the timezone is acceptable. Length 1 octet. 383 3.1.1. Link Speed Encoding 385 The speed is encoded using 2 octets as follows: 387 0 1 388 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | Exponent | Significand | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 Using this format, the speed of the link is Significand * 10 ^ 394 Exponent kbps. This allows specifying link speeds with up to 3 395 decimal digits precision and speeds from 1 kbps to 10 ^ 67 kbps. A 396 computed speed of 0 kbps means the link speed is < 1 kbps. 398 Here are some examples how this is used: 400 Link Speed Exponent Significand 401 ------------ ---------- ------------- 402 500 kbps 0 500 403 500 kbps 2 5 404 155 Mbps 3 155 405 40 Gpbs 6 40 406 100 Gpbs 6 100 407 100 Gpbs 8 1 409 3.2. Example message layouts 411 We will here give a few examples to illustrate the use of flags and 412 options. 414 A minimum size message has no option flags set, and looks like this: 416 0 1 2 3 417 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 |F|E| Attr Type | Length = 6 | Effective MTU | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | Unalloc/Reserved |P|a|t|A|S|0|0|0|0|0|0|0|0| Unalloc/Rsrvd | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 A message containing all the options defined in this document would 425 look like this: 427 0 1 2 3 428 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 |F|E| Attr Type | Length = 18 | Effective MTU | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 | Unalloc/Reserved |P|a|t|A|S|1|1|1|1|1|1|1|1| Unalloc/Rsrvd | 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 | Transit Oif-List Count | 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 | Stub Oif-List Count | 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 | Minimum Speed Link | Maximum Speed Link | 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 | Domain Count | Node Count | Diameter Count| TZ Count | 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 A message containing only Stub Oif-List Count and Node Count would 444 look like this: 446 0 1 2 3 447 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 |F|E| Attr Type | Length = 9 | Effective MTU | 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 | Unalloc/Reserved |P|a|t|A|S|0|1|0|0|0|1|0|0| Unalloc/Rsrvd | 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 | Stub Oif-List Count | 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 | Node count | 456 +-+-+-+-+-+-+-+-+ 458 4. How to use Pop-Count Encoding 460 A router supporting this mechanism MUST, unless administratively 461 disabled, include the PIM Join Attribute option in its PIM Hellos. 462 See [RFC5384] and [HELLO] for details. 464 It is RECOMMENDED that implementations allow for administrative 465 control whether to make use of this mechanism. Implementations MAY 466 also allow further control of what information to store and send 467 upstream. 469 It is very important to note that any changes to the values 470 maintained by this mechanism MUST NOT trigger a new Join/Prune 471 message. Due to the periodic nature of PIM, the values can be 472 accurately obtained at 1 minute intervals (or whatever Join/Prune 473 interval used). 475 When a router removes a link from an oif-list, it need to be able to 476 reevaluate the values that it will advertise upstream. This happens 477 when an oif-list entry is timed out or a Prune is received. 479 It is RECOMMENDED that the Join Attribute defined in this document be 480 used only for entries in the join-list part of the Join/Prune 481 message. If the attribute is used in the prune-list, an 482 implementation MUST ignore it and process the Prune as if the 483 attribute was not present. 485 It is also RECOMMENDED that join suppression be disabled on a LAN 486 when Pop-Count is used. 488 It is RECOMMENDED that when triggered Join/Prune messages are sent by 489 a downstream router, that the accounting information not be included 490 in the message. This way when convergence is important, avoiding the 491 processing time to build an accounting record in a downstream router 492 and processing time to parse the message in the upstream router will 493 help reduce convergence time. An upstream router SHOULD NOT 494 interpret a Join/Prune message received with no accounting data to 495 mean clearing or resetting what accounting data it has cached. 497 5. Implementation Approaches 499 This section offers some non-normative suggestions for how pop-count 500 may be be implemented. 502 An implementation can decide how the accounting attributes are 503 maintained. The values can be stored as part of the multicast route 504 data structure by combining the local information it has with the 505 joined information on a per oif basis. So when it is time to send a 506 Join/Prune message, the values stored in the multicast route can be 507 copied to the message. 509 Or, an implementation could store the accounting values per oif and 510 when a Join/Prune message is sent, it can combine the oifs with its 511 local information. Then the combined information can be copied to 512 the message. 514 When a downstream joiner stops joining, accounting values cached must 515 be evaluated. There are two approaches which can be taken. One is 516 to keep values learned from each joiner so when the joiner goes away 517 the count/max/min values are known and the combined value can be 518 adjusted. The other approach is to set the value to 0 for the oif, 519 and then start accumulating new values as subsequent Joins are 520 received. 522 The same issue arises when an oif is removed from the oif-list. 523 Keeping per-oif values allows you to adjust the per-route values when 524 an oif goes away. Or, alternatively, a delay for reporting the new 525 set a values from the route can occur while all oif values are zeroed 526 (where accumulation of new values from subsequent Joins cause re- 527 population of values and a new max/min/count can be reevaluated for 528 the route). 530 6. Caveats 532 This specification requires each router on a multicast distribution 533 tree to support this specification or else the accounting attributes 534 for the tree will not be known. 536 However, if there are a contiguous set of routers downstream in the 537 distribution tree, they can maintain accounting information for the 538 sub-tree. 540 If there are a set of contiguous routers supporting this 541 specification upstream on the multicast distribution tree, accounting 542 information will be available but it will not represent an accurate 543 assessment of the entire tree. Also, it will not be clear for how 544 much of the distribution tree the accounting information covers. 546 7. IANA Considerations 548 A new PIM Hello Option type, 29, has been assigned temporarily. The 549 string TBD1 needs to be replaced with the permanently assigned value. 550 See [HELLO] for details. Although the length is specified as 0 in 551 this specifications, non-zero length is allowed, so IANA should list 552 the length as being variable. 554 A new PIM Join Attribute type needs to be assigned. The string TBD2 555 needs to be replaced with the assigned value. 557 8. Security Considerations 559 The use of this specification requires some additional processing of 560 PIM Join/Prune messages. However, the additional amount of 561 processing is fairly limited, so this is not believed to be a 562 significant concern. 564 The use of this mechanism includes information like the number of 565 receivers. This information is assumed to not be of sensitive 566 nature. If an operator has concerns about revealing this information 567 to upstream routers, or other routers/hosts that may potentially 568 inspect this information, there should be a way to disable the 569 mechanism, or alternatively more detailed control of what information 570 to include. 572 9. Acknowledgments 574 The authors would like to thank John Zwiebel, Amit Jain, and Clayton 575 Wagar for their review comments on the initial versions of this 576 document. Adrian Farrel did a detailed review of the document and 577 proposed textual changes that have been incorporated. Further review 578 and comments were provided by Thomas Morin and Zhaohui (Jeffrey) 579 Zhang. 581 10. References 583 10.1. Normative References 585 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 586 Requirement Levels", BCP 14, RFC 2119, March 1997. 588 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 589 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 590 Protocol Specification (Revised)", RFC 4601, August 2006. 592 [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, 593 "Bidirectional Protocol Independent Multicast (BIDIR- 594 PIM)", RFC 5015, October 2007. 596 [RFC5384] Boers, A., Wijnands, I., and E. Rosen, "The Protocol 597 Independent Multicast (PIM) Join Attribute Format", 598 RFC 5384, November 2008. 600 10.2. Informative References 602 [HELLO] IANA, "PIM-Hello Options", 603 . 605 [I-D.ietf-mboned-auto-multicast] 606 Bumgardner, G., "Automatic Multicast Tunneling", 607 draft-ietf-mboned-auto-multicast-14 (work in progress), 608 June 2012. 610 Authors' Addresses 612 Dino Farinacci 613 Cisco Systems 614 Tasman Drive 615 San Jose, CA 95134 616 USA 618 Email: dino@cisco.com 620 Greg Shepherd 621 Cisco Systems 622 Tasman Drive 623 San Jose, CA 95134 624 USA 626 Email: gjshep@gmail.com 628 Stig Venaas 629 Cisco Systems 630 Tasman Drive 631 San Jose, CA 95134 632 USA 634 Email: stig@cisco.com 636 Yiqun Cai 637 Microsoft 638 1065 La Avenida 639 Mountain View, CA 94043 640 USA 642 Email: yiqunc@microsoft.com