Network Working Group Dino Farinacci Internet-Draft Greg Shepherd Intended status: Experimental Yiqun Cai Expires: July 8, 2012 Stig Venaas cisco Systems January 5, 2012 Population Count Extensions to PIM draft-ietf-pim-pop-count-05.txt Abstract This specification defines a method for providing multicast distribution-tree accounting data. Simple extensions to the PIM protocol allow a rough approximation of tree-based data in a scalable fashion. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on July 8, 2012. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as Dino Farinacci, et al. Expires July 8, 2012 [Page 1] Internet-Draft Population Count Extensions to PIM January 2012 described in the Simplified BSD License. Table of Contents 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 3. New Hello TLV Pop-Count Support . . . . . . . . . . . . . . . 5 4. New Pop-Count Join Attribute Format . . . . . . . . . . . . . 6 4.1. Options . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1.1. Link Speed Encoding . . . . . . . . . . . . . . . . . 10 4.2. Example message layouts . . . . . . . . . . . . . . . . . 11 5. How to use Pop-Count Encoding . . . . . . . . . . . . . . . . 13 6. Implementation Approaches . . . . . . . . . . . . . . . . . . 14 7. Caveats . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 11.1. Normative References . . . . . . . . . . . . . . . . . . . 19 11.2. Informative References . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Dino Farinacci, et al. Expires July 8, 2012 [Page 2] Internet-Draft Population Count Extensions to PIM January 2012 1. Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Dino Farinacci, et al. Expires July 8, 2012 [Page 3] Internet-Draft Population Count Extensions to PIM January 2012 2. Introduction This draft proposes a mechanism to convey accounting information using the PIM protocol [RFC4601] [RFC5015]. Putting the mechanism in PIM allows efficient distribution and maintenance of such accounting information. Previous mechanisms require data to be correlated from multiple router sources. This proposal allows a single router to be queried to obtain accounting and statistic information for a multicast distribution tree as a whole or any distribution sub-tree downstream from a queried router. The amount of information is fixed and does not increase as multicast membership, tree diameter, or branching increase. The sort of accounting data this draft provides, on a per multicast route basis, are: 1. The number of branches in a distribution tree. 2. The membership type of the distribution tree, that is SSM or ASM. 3. Routing domain and time zone boundary information. 4. On-tree node and tree diameter counters. 5. Effective MTU and bandwidth. This draft adds a new PIM Join Attribute type [RFC5384] to the Join/ Prune message as well as a new Hello TLV. The mechanism is applicable to IPv4 and IPv6 multicast. 2.1. Terminology This section defines the terms used in this draft. Multicast Route: A (S,G) or (*,G) entry regardless if the route is in ASM, SSM, or Bidir mode of operation. Stub Link: A link with members joined to the group via IGMP or MLD. Transit Link: A link put in the oif-list for a multicast route because it was joined by PIM routers. Note that a link can be both a Stub Link and a Transit Link at the same time. Dino Farinacci, et al. Expires July 8, 2012 [Page 4] Internet-Draft Population Count Extensions to PIM January 2012 3. New Hello TLV Pop-Count Support When a PIM router sends a Join/Prune message to a neighbor, it will encode the data in a new PIM Join Attribute type (described in this draft) when the PIM router determines the neighbor can support this draft. If a PIM router supports this draft, it must send the Pop- Count-Supported TLV. The format of the TLV is defined to be: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OptionType | OptionLength | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OptionValue | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ OptionType = 29, OptionLength = 4, there is no OptionValue semantics defined at this time but will be included for expandability and be defined in future revisions of this draft. The format will look like: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 29 | 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Unallocated Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Unallocated Flags: for now should be sent as 0 and ignored on receipt. Dino Farinacci, et al. Expires July 8, 2012 [Page 5] Internet-Draft Population Count Extensions to PIM January 2012 4. New Pop-Count Join Attribute Format When a PIM router supports this draft and has determined from a received Hello, the neighbor supports this draft, it will send Join/ Prune messages that MAY include a Pop-Count attribute. The mechanism to process PIM Join Attribute is described in [RFC5384]. The format of the new attribute is described in the following. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F|E| Attr Type | Length | Effective MTU | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Options Bitmap | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options | . . . . . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The above format is used only for entries in the join-list section of the Join/Prune message. F bit: 0 Non-Transitive Attribute. E bit: As specified by [RFC5384]. Attr Type: 2. Length: The minimum length is 6. Effective MTU: This contains the minimum MTU for any link in the oif-list. The sender of Join/Prune message takes the minimum value for the MTU (in bytes) from each link in the oif-list. If this value is less than the value stored for the multicast route (the one received from downstream joiners) then the value should be reset and sent in Join/Prune message. Otherwise, the value should remain unchanged. This provides one to obtain the MTU supported by multicast distribution tree when examined at the first-hop router(s) or for sub-tree for any router on the distribution tree. Dino Farinacci, et al. Expires July 8, 2012 [Page 6] Internet-Draft Population Count Extensions to PIM January 2012 Flags: The flags field has the following format: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Unalloc/Reserved |P|a|t|A|S| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Unallocated Flags: The flags which are currently not defined. If a new flag is defined and sent by a new implementation, an old implementation should preserve the bit settings. This means that if a bit was set in a PIM Join message from any of the downstream routers, then it MUST also be set in any PIM Join sent upstream. S flag: If an IGMPv3 or MLDv2 report was received on any oif- list entry or the bit was set from any PIM Join message. This bit should only be cleared when the above becomes untrue. A flag: If an IGMPv1, IGMPv2, or MLDv1 report was received on any oif-list entry or the bit was set from any PIM Join message. This bit should only be cleared when the above becomes untrue. A combination of settings for these bits indicate: A-flag S-flag Description ------ ------ ----------------------------------------- 0 0 There are no members for the group ('Stub Oif-List Count' is 0) 0 1 All group members are only SSM capable 1 0 All group members are only ASM capable 1 1 There is a mixture of SSM and ASM capable t flag: If there are any tunnels on the distribution tree. If a tunnel is in the oif-list, a router should set this bit in its Join/Prune messages. Otherwise, it propagates the bit setting from downstream joiners. a flag: If there are any auto-tunnels on the distribution tree. If an auto-tunnel is in the oif-list, a router should set this bit in its Join/Prune messages. Otherwise, it propagates the bit setting from downstream joiners. An example of an auto- tunnel is an tunnel setup by the AMT [AMT] protocol. Dino Farinacci, et al. Expires July 8, 2012 [Page 7] Internet-Draft Population Count Extensions to PIM January 2012 P flag: This flag remains set if all downstream routers support this specification. That is, they are PIM pop-count capable. This allows one to tell if the entire sub-tree is completely accounting capable. Options Bitmap: This is a bitmap that shows which options are present. The format of the bitmap is as follows: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |T|s|m|M|d|n|D|z| Unalloc/Rsrvd | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Each one of the bits T, s, m, M, d, n, D and z is associated with one option, where the option is included if and only if the respective bit is set. Included options MUST be in the same order as these bits are listed. The bits denote the following options: bit Option ----- ------------------------ T Transit Oif-List Count s Stub Oif-List Count m Minimum Speed Link M Maximum Speed Link d Domain Count n Node Count D Diameter Count z TZ Count See Section 4.1 for details on the different options. The unallocated bits are reserved. Any unknown bits MUST be set to 0 when a message is sent, and treated as 0 (ignored) when received. This means that unknown options which are denoted by unknown bits are ignored. By using this bitmap we can specify at most 16 options. If there becomes a need for more than 16 options, one can define a new option that contains a bitmap, which can then be used to specify which further options are present. The last bit in the current bitmap could be used for that option. The exact definition of this is however left for future documents. Dino Farinacci, et al. Expires July 8, 2012 [Page 8] Internet-Draft Population Count Extensions to PIM January 2012 Options: This field contains options. Which options are present are determined by the flag bits. As new flags and options may be defined in the future, any unknown/reserved flags MUST be ignored, and any additional trailing options MUST be ignored. See Section 4.1 for details on the options defined in this document. 4.1. Options There are several options defined in this document. For each option, there is also a related flag that shows whether the option is present. See the Options Bitmap above for a list of the options and their respective bits. Each option has a fixed size. Transit Oif-List Count: This is filled in by a router sending a Join/Prune message which is equal to the number of oifs for the multicast route that has been joined by PIM. This indicates the transit branches on a multicast distribution tree (no members on the links between this router and joining routers). This is added to the value advertised by all downstream PIM routers that have joined on this oif. Length 2 octets. Stub Oif-List Count: This is filled in by a router sending a Join/ Prune message which is equal to the number of oifs for the multicast route that has been joined by IGMP or MLD. This indicates the links where there are host members for the multicast route. This is added to the value advertised by all downstream PIM routers that have joined on this oif. Length 2 octets. Minimum Speed Link: This contains the minimum bandwidth rate for any link in the oif-list and is encoded as specified in Section 4.1.1. The sender of Join/Prune message takes the minimum value for each link in the oif-list for the multicast route. If this value is less than the value stored for the multicast route (the one received from downstream joiners) then the value should be reset and sent in Join/Prune message. Otherwise, the value should remain unchanged. This together with the Maximum Speed Link option provides a way to obtain the lowest and highest speed link for the multicast distribution tree. Length 2 octets. Maximum Speed Link: This contains the maximum bandwidth rate for any link in the oif-list and is encoded as specified in Section 4.1.1. The sender of Join/Prune message takes the maximum value for each link in the oif-list for the multicast route. If this value is greater than the value stored for the multicast route (the one received from downstream joiners) then the value should be reset and sent in Join/Prune message. Otherwise, the value should remain unchanged. This together with the Minimum Speed Link option provides a way to obtain the lowest and highest Dino Farinacci, et al. Expires July 8, 2012 [Page 9] Internet-Draft Population Count Extensions to PIM January 2012 speed link for the multicast distribution tree. Length 2 octets. Domain Count: This indicates the number of routing domains the distribution tree traverses. A router should increment this value if it is sending a Join/Prune message over a link which traverses a domain boundary. Length 1 octet. Node Count: This indicates the number of routers on the distribution tree. Each router will sum up all the Node Counts from all joiners on all oifs and increment by 1 before including this value in the Join/Prune message. Length 1 octet. Diameter Count: This indicates the longest length of any given branch of the tree in router hops. Each router that sends a Join increments the max value received by all downstream joiners by 1. Length 1 octet. TZ Count: This indicates the number of timezones the distribution tree traverses. A router should increment this value if it is sending a Join/Prune message over a link which traverses a time zone. This can be a configured link attribute or use other means to determine the timezone is acceptable. Length 1 octet. 4.1.1. Link Speed Encoding The speed is encoded using 2 octets as follows: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Exponent | Significand | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Using this format, the speed of the link is Significand * 10 ^ Exponent kbps. This allows specifying link speeds with up to 3 decimal digits precision and speeds from 1 kbps to 10 ^ 67 kbps. A computed speed of 0 kbps means the link speed is < 1 kbps. Here are some examples how this is used: Dino Farinacci, et al. Expires July 8, 2012 [Page 10] Internet-Draft Population Count Extensions to PIM January 2012 Link Speed Exponent Significand ------------ ---------- ------------- 500 kbps 0 500 500 kbps 2 5 155 Mbps 3 155 40 Gpbs 6 40 100 Gpbs 6 100 100 Gpbs 8 1 4.2. Example message layouts We will here give a few examples to illustrate the use of flags and options. A minimum size message has no option flags set, and looks like this: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F|E| Attr Type | Length = 6 | Effective MTU | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Unalloc/Reserved |P|a|t|A|S|0|0|0|0|0|0|0|0| Unalloc/Rsrvd | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A message containing all the options defined in this document would look like this: