idnits 2.17.1 draft-farinacci-pim-pop-count-02.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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 455. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 466. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 473. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 479. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 230 has weird spacing: '... a-flag s-fl...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 26, 2008) is 5897 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-08 -- Duplicate reference: RFC4601, mentioned in 'HELLO', was also mentioned in 'RFC4601'. -- Obsolete informational reference (is this intentional?): RFC 4601 (ref. 'HELLO') (Obsoleted by RFC 7761) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 9 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 cisco Systems 5 Expires: August 29, 2008 February 26, 2008 7 Population Count Extensions to PIM 8 draft-farinacci-pim-pop-count-02.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on August 29, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2008). 39 Abstract 41 This specification defines a method for providing multicast 42 distribution-tree accounting data for billing and debugging. Simple 43 extensions to the PIM protocol allow a rough approximation of tree- 44 based data in a scalable fashion. 46 Table of Contents 48 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 49 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 50 2.1. Status of Draft . . . . . . . . . . . . . . . . . . . . . 4 51 2.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 2.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 53 3. New Hello TLV Pop-Count Support . . . . . . . . . . . . . . . 6 54 4. New Encoded-Source-Address Format . . . . . . . . . . . . . . 7 55 5. How to use Pop-Count Encoding . . . . . . . . . . . . . . . . 10 56 6. Implementation Approaches . . . . . . . . . . . . . . . . . . 11 57 7. Caveats . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 58 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 59 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 60 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 61 10.1. Normative References . . . . . . . . . . . . . . . . . . . 15 62 10.2. Informative References . . . . . . . . . . . . . . . . . . 15 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 64 Intellectual Property and Copyright Statements . . . . . . . . . . 17 66 1. Requirements Notation 68 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 69 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 70 document are to be interpreted as described in [RFC2119]. 72 2. Introduction 74 2.1. Status of Draft 76 This draft was originally written in May of 2004 and presented at the 77 PIM working group in San Diego in August of 2004. At that time, the 78 working group was not interested in pursuing this work. At the 79 Vancouver IETF in December of 2007, there seem to be renewed interest 80 in the design. So it is being submitted for the working group to 81 decide if it should become a working group document. 83 2.2. Overview 85 This draft proposes a mechanism to convey accounting information 86 using the PIM protocol [RFC4601] [RFC5015]. Putting the mechanism in 87 PIM allows efficient distribution and maintenance of such accounting 88 information. Previous mechanisms require data to be correlated from 89 multiple router sources. 91 This proposal allows a single router to be queried to obtain 92 accounting and statistic information for a multicast distribution 93 tree as a whole or any distribution sub-tree downstream from a 94 queried router. The amount of information is fixed and does not 95 increase as multicast membership, tree diameter, or branching 96 increase. 98 The sort of accounting data this draft provides, on a per multicast 99 route basis, are: 101 1. The number of branches in a distribution tree. 103 2. The membership type of the distribution tree, that is SSM or ASM. 105 3. Routing domain and time zone boundary information. 107 4. On-tree node and tree diameter counters. 109 5. Effective MTU and bandwidth. 111 This draft adds a new Encoded-Source-Address format to the Join/Prune 112 message as well as a new Hello TLV. The mechanism is applicable to 113 IPv4 and IPv6 multicast. See [HELLO] for details. 115 2.3. Terminology 117 This section defines the terms used in this draft. 119 Multicast Route: A (S,G) or (*,G) entry regardless if the route is 120 in ASM, SSM, or Bidir mode of operation. 122 Stub Link: A link with only members joined to the group via IGMP or 123 MLD. Which means there are no PIM routers joining for the 124 multicast route on the link. 126 Transit Link: A link put in the oif-list for a multicast route 127 because it was joined by PIM routers only (no IGMP or MLD reports 128 were received on the link). 130 Dual Link: Is a link in the oif-list which is has the attributes of 131 a Stub Link *and* Transit Link. That is, there are IGMP and MLD 132 members as well as PIM joiners for the multicast route on the 133 link. 135 3. New Hello TLV Pop-Count Support 137 When a PIM router sends a Join/Prune message to a neighbor, it will 138 use the new form of the Encoded-Source-Address (described in this 139 draft) when the PIM router determines the neighbor can support this 140 draft. If a PIM router supports this draft, it must send the Pop- 141 Count-Supported TLV. The format of the TLV is defined to be: 143 0 1 2 3 144 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 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 | OptionType | OptionLength | 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 | OptionValue | 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 OptionType = 26, OptionLength = 8, there is no OptionValue semantics 152 defined at this time but will be included for expandability and be 153 defined in future revisions of this draft. The format will look 154 like: 156 0 1 2 3 157 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 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 | 26 | 8 | 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | Unallocated Flags | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 Unallocated Flags: for now should be sent as 0 and ignored on 165 receipt. This field could be used to enable the use of future 166 flags in the Unallocated Flags field of the new Encoded-Source- 167 Address format defined below. 169 4. New Encoded-Source-Address Format 171 When a PIM router supports this draft and has determined from a 172 received Hello, the neighbor supports this draft, it will send Join/ 173 Prune messages with the following format: 175 0 1 2 3 176 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 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | Addr Family | Encoding Type | Rsrvd |S|W|R| Mask Len | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | Source Address | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 | Effective MTU | Unallocated Flags (Reserved) |P|a|t|A|S| 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 | Domain Count | Node Count | Diameter Count| TZ Count | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | Transit Oif-List Count | Stub Oif-List Count | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | Minimum Speed Link | Maximum Speed Link | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 The above format is used only for entries in the join-list section of 192 the Join/Prune message. 194 The format is identical to the format defined for the Address-Family 195 [AFI] independent Encoded-Source-Address in [RFC4601] except there 196 are additional fields appended. What distinguishes the above format 197 from the format in [RFC4601] is the use of a different Encoding Type 198 format. If the Encoding Type value is 1, the above format will be 199 used. 201 The additional fields are: 203 Effective MTU: this contains the minimum MTU for any link in the 204 oif-list. The sender of Join/Prune message takes the minimum 205 value for the MTU (in bytes) from each link in the oif-list. If 206 this value is less than the value stored for the multicast route 207 (the one received from downstream joiners) then the value should 208 be reset and sent in Join/Prune message. Otherwise, the value 209 should remain unchanged. The value is in units of 10s of bytes 210 (i.e. so the value for a traditional Ethernet MTU would be 150). 212 This provides one to obtain the MTU supported by multicast 213 distribution tree when examined at the first-hop router(s) or for 214 sub-tree for any router on the distribution tree. 216 Unallocated Flags: The flags which are currently not defined. If a 217 new flag is defined and sent by a new implementation, an old 218 implementation should preserve the bit settings. 220 S flag: if an IGMPv3 or MLDv2 report was received on any oif-list 221 entry or the bit was set from any PIM Join message. This bit 222 should only be cleared when the above becomes untrue. 224 A flag: if an IGMPv1, IGMPv2, or MLDv1 report was received on any 225 oif-list entry or the bit was set from any PIM Join message. This 226 bit should only be cleared when the above becomes untrue. 228 A combination of settings for these bits indicate: 230 a-flag s-flag Description 231 ------ ------ ----------------------------------------- 232 0 0 There are no members for the group 233 ('Stub Oif-List Count' is 0) 234 0 1 All group members are only SSM capable 235 1 0 All group members are only ASM capable 236 1 1 There is a mixture of SSM and ASM capable 238 t flag: if there are any tunnels on the distribution tree. If a 239 tunnel is in the oif-list, a router should set this bit in it's 240 Join/Prune messages. Otherwise, it propagates the bit setting 241 from downstream joiners. 243 a flag: if there are any auto-tunnels on the distribution tree. If 244 an auto-tunnel is in the oif-list, a router should set this bit in 245 it's Join/Prune messages. Otherwise, it propagates the bit 246 setting from downstream joiners. An example of an auto-tunnel is 247 an tunnel setup by the AMT [AMT] protocol. 249 P flag: this flag remains set if all downstream routers support 250 this specification. That is, they are PIM pop-count capable. 251 This allows one to tell if the entire sub-tree is completely 252 accounting capable. 254 Domain Count: this indicates the number of routing domains the 255 distribution tree traverses. A router should increment this value 256 if it is sending a Join/Prune message over a link which traverses 257 a domain boundary. 259 Node Count: This indicates the number of routers on the 260 distribution tree. Each router will sum up all the Node Counts 261 from all joiners on all oifs and increment by 1 before including 262 this value in the Join/Prune message. 264 Diameter Count: this indicates the longest length of any given 265 branch of the tree in router hops. Each router that sends a Join 266 increments the max value received by all downstream joiners by 1. 268 TZ Count: this indicates the number of timezones the distribution 269 tree traverses. A router should increment this value if it is 270 sending a Join/Prune message over a link which traverses a time 271 zone. This can be a configured link attribute or use other means 272 to determine the timezone is acceptable. 274 Transit Oif-List Count: is filled in by a router sending a Join/ 275 Prune message which is equal to the number of oifs for the 276 multicast route that has been joined by PIM only. This indicates 277 the transit branches on a multicast distribution tree (no members 278 on the links between this router and joining routers). This is 279 added to the value advertised by all downstream PIM routers that 280 have joined on this oif. 282 Stub Oif-List Count: is filled in by a router sending a Join/Prune 283 message which is equal to the number of oifs for the multicast 284 route that has been joined only by IGMP or MLD. This indicates 285 the links where there are host members for the multicast route. 286 This is added to the value advertised by all downstream PIM 287 routers that have joined on this oif. 289 Minimum Speed Link: this contains the minimum bandwidth rate (in 290 mbps) for any link in the oif-list. The sender of Join/Prune 291 message takes the minimum value for each link in the oif-list for 292 the multicast route. If this value is less than the value stored 293 for the multicast route (the one received from downstream joiners) 294 then the value should be reset and sent in Join/Prune message. 295 Otherwise, the value should remain unchanged. A value of 0 means 296 the link speed is < 1 mbps. 298 Maximum Speed Link: this contains the maximum bandwidth rate (in 299 mbps) for any link in the oif-list. The sender of Join/Prune 300 message takes the maximum value for each link in the oif-list for 301 the multicast route. If this value is greater than the value 302 stored for the multicast route (the one received from downstream 303 joiners) then the value should be reset and sent in Join/Prune 304 message. Otherwise, the value should remain unchanged. A value 305 of 0 means the link speed is < 1 mbps. 307 This provides a way to obtain the lowest and highest speed link for 308 the multicast distribution tree. 310 5. How to use Pop-Count Encoding 312 It is very important to note that any changes to the values 313 maintained in this draft *must not* trigger a new Join/Prune message. 314 Due to the periodic nature of PIM, the values can be accurately 315 obtained at 1 minute intervals (or whatever Join/Prune interval 316 used). 318 When a router removes a link from an oif-list, it must be able to 319 reevaluate the values that it will advertise upstream. This happens 320 when an oif-list entry is timed out or a Prune is received. 322 It is recommended that the Encoded-Source-Address defined in this 323 draft be used for entries in the join-list part of the Join/Prune 324 message. If the new encoding is used in the prune-list, an 325 implementation must ignore them but still process the Prune as if it 326 was in the original encoding described in [RFC4601]. 328 6. Implementation Approaches 330 An implementation can decide how the accounting attributes are 331 maintained. The values can be stored as part of the multicast route 332 data structure by combining the local information it has with the 333 joined information on a per oif basis. So when it is time to send a 334 Join/Prune message, the values stored in the multicast route can be 335 copied to the message. 337 Or, an implementation could store the accounting values per oif and 338 when a Join/Prune message is sent, it can combine the oifs with it's 339 local information. Then the combined information can be copied to 340 the message. 342 When a downstream joiner stops joining, accounting values cached must 343 be evaluated. There are two approaches which can be taken. One is 344 to keep values learned from each joiner so when the joiner goes away 345 the count/max/min values are known and the combined value can be 346 adjusted. The other approach is to set the value to 0 for the oif, 347 and then start accumulating new values as subsequent Joins are 348 received. 350 The same issue arises when an oif is removed from the oif-list. 351 Keeping per-oif values allows you to adjust the per-route values when 352 an oif goes away. Or, alternatively, a delay for reporting the new 353 set a values from the route can occur while all oif values are zeroed 354 (where accumulation of new values from subsequent Joins cause re- 355 population of values and a new max/min/ count can be reevaluated for 356 the route). 358 It is recommended that when triggered Join/Prune messages are sent by 359 a downstream router, that the accconting information not be included 360 in the message. This way when convergence is important, avoiding the 361 processing time to build an accounting record in a downstream router 362 and processing time to parse the message in the upstream router will 363 help reduce convergence time. An upstream router should not 364 interpret a Join/Prune message received with no acccounting data to 365 mean clearing or resetting what accounting data it has cached. 367 7. Caveats 369 This draft requires each router on a multicast distribution tree to 370 support this draft or else the accounting attributes for the tree 371 will not be known. 373 However, if there are a contiguous set of routers downstream in the 374 distribution tree, they can maintain accounting information for the 375 sub-tree. 377 If there are a set of contiguous routers supporting this draft 378 upstream on the multicast distribution tree, accounting information 379 will be available but it will not represent an accurate assessment of 380 the entire tree. Also, it will not be clear for how much of the 381 distribution tree the accounting information covers. 383 8. Security Considerations 385 There are no security considerations for this design other than what 386 is already in the main PIM specification [RFC4601]. 388 9. Acknowledgments 390 The authors would like to thank John Zwiebel, Amit Jain, and Clayton 391 Wagar for their review comments on the initial versions of this 392 draft. 394 10. References 396 10.1. Normative References 398 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 399 Requirement Levels", BCP 14, RFC 2119, March 1997. 401 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 402 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 403 Protocol Specification (Revised)", RFC 4601, August 2006. 405 [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, 406 "Bidirectional Protocol Independent Multicast (BIDIR- 407 PIM)", RFC 5015, October 2007. 409 10.2. Informative References 411 [AFI] IANA, "Address Family Indicators (AFIs)", ADDRESS FAMILY 412 NUMBERS http://www.iana.org/numbers.html, February 2007. 414 [AMT] Thaler, D., Talwar, M., Aggarwal, A., Vicisano, L., and T. 415 Pusateri, "Automatic IP Multicast Without Explicit 416 Tunnels (AMT)", draft-ietf-mboned-auto-multicast-08.txt 417 (work in progress), October 2007. 419 [HELLO] IANA, "PIM Hello Options", PIM-HELLO-OPTIONS per 420 RFC4601 http://www.iana.org/assignments/pim-hello-options, 421 March 2007. 423 Authors' Addresses 425 Dino Farinacci 426 cisco Systems 427 Tasman Drive 428 San Jose, CA 95134 429 USA 431 Email: dino@cisco.com 433 Greg Shepherd 434 cisco Systems 435 Tasman Drive 436 San Jose, CA 95134 437 USA 439 Email: shep@cisco.com 441 Full Copyright Statement 443 Copyright (C) The IETF Trust (2008). 445 This document is subject to the rights, licenses and restrictions 446 contained in BCP 78, and except as set forth therein, the authors 447 retain all their rights. 449 This document and the information contained herein are provided on an 450 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 451 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 452 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 453 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 454 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 455 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 457 Intellectual Property 459 The IETF takes no position regarding the validity or scope of any 460 Intellectual Property Rights or other rights that might be claimed to 461 pertain to the implementation or use of the technology described in 462 this document or the extent to which any license under such rights 463 might or might not be available; nor does it represent that it has 464 made any independent effort to identify any such rights. Information 465 on the procedures with respect to rights in RFC documents can be 466 found in BCP 78 and BCP 79. 468 Copies of IPR disclosures made to the IETF Secretariat and any 469 assurances of licenses to be made available, or the result of an 470 attempt made to obtain a general license or permission for the use of 471 such proprietary rights by implementers or users of this 472 specification can be obtained from the IETF on-line IPR repository at 473 http://www.ietf.org/ipr. 475 The IETF invites any interested party to bring to its attention any 476 copyrights, patents or patent applications, or other proprietary 477 rights that may cover technology that may be required to implement 478 this standard. Please address the information to the IETF at 479 ietf-ipr@ietf.org. 481 Acknowledgment 483 Funding for the RFC Editor function is provided by the IETF 484 Administrative Support Activity (IASA).