draft-ietf-pim-pop-count-01.txt   draft-ietf-pim-pop-count-02.txt 
Network Working Group Dino Farinacci Network Working Group Dino Farinacci
Internet-Draft Greg Shepherd Internet-Draft Greg Shepherd
Intended status: Experimental Yiqun Cai Intended status: Experimental Yiqun Cai
Expires: January 2, 2010 cisco Systems Expires: September 5, 2010 cisco Systems
July 1, 2009 March 4, 2010
Population Count Extensions to PIM Population Count Extensions to PIM
draft-ietf-pim-pop-count-01.txt draft-ietf-pim-pop-count-02.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 Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 33 skipping to change at page 1, line 40
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 2, 2010. This Internet-Draft will expire on September 5, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
This specification defines a method for providing multicast described in the BSD License.
distribution-tree accounting data. Simple extensions to the PIM
protocol allow a rough approximation of tree-based data in a scalable
fashion.
Table of Contents Table of Contents
1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
3. New Hello TLV Pop-Count Support . . . . . . . . . . . . . . . 6 3. New Hello TLV Pop-Count Support . . . . . . . . . . . . . . . 6
4. New Pop-Count Join Attribute Format . . . . . . . . . . . . . 7 4. New Pop-Count Join Attribute Format . . . . . . . . . . . . . 7
5. How to use Pop-Count Encoding . . . . . . . . . . . . . . . . 10 5. How to use Pop-Count Encoding . . . . . . . . . . . . . . . . 10
6. Implementation Approaches . . . . . . . . . . . . . . . . . . 11 6. Implementation Approaches . . . . . . . . . . . . . . . . . . 11
skipping to change at page 6, line 21 skipping to change at page 6, line 21
Count-Supported TLV. The format of the TLV is defined to be: Count-Supported TLV. The format of the TLV is defined to be:
0 1 2 3 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 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 | | OptionType | OptionLength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OptionValue | | OptionValue |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
OptionType = 27, OptionLength = 8, there is no OptionValue semantics OptionType = 29, OptionLength = 8, there is no OptionValue semantics
defined at this time but will be included for expandability and be defined at this time but will be included for expandability and be
defined in future revisions of this draft. The format will look defined in future revisions of this draft. The format will look
like: like:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 27 | 8 | | 29 | 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unallocated Flags | | Unallocated Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Unallocated Flags: for now should be sent as 0 and ignored on Unallocated Flags: for now should be sent as 0 and ignored on
receipt. This field could be used to enable the use of future receipt.
flags in the Unallocated Flags field of the new Encoded-Source-
Address format defined below.
4. New Pop-Count Join Attribute Format 4. New Pop-Count Join Attribute Format
When a PIM router supports this draft and has determined from a When a PIM router supports this draft and has determined from a
received Hello, the neighbor supports this draft, it will send Join/ received Hello, the neighbor supports this draft, it will send Join/
Prune messages that MAY include a Pop-Count attribute. The mechanism Prune messages that MAY include a Pop-Count attribute. The mechanism
to process PIM Join Attribute is described in [RFC5384]. The format to process PIM Join Attribute is described in [RFC5384]. The format
of the new attribute is described in the following. of the new attribute is described in the following.
0 1 2 3 0 1 2 3
skipping to change at page 10, line 11 skipping to change at page 10, line 11
This provides a way to obtain the lowest and highest speed link for This provides a way to obtain the lowest and highest speed link for
the multicast distribution tree. the multicast distribution tree.
5. How to use Pop-Count Encoding 5. How to use Pop-Count Encoding
A router supporting this draft MUST include PIM Join Attribute TLV in A router supporting this draft MUST include PIM Join Attribute TLV in
its PIM Hellos. See [RFC5384] and [HELLO] for detail. its PIM Hellos. See [RFC5384] and [HELLO] for detail.
It is very important to note that any changes to the values It is very important to note that any changes to the values
maintained in this draft *must not* trigger a new Join/Prune message. maintained in this draft MUST NOT trigger a new Join/Prune message.
Due to the periodic nature of PIM, the values can be accurately Due to the periodic nature of PIM, the values can be accurately
obtained at 1 minute intervals (or whatever Join/Prune interval obtained at 1 minute intervals (or whatever Join/Prune interval
used). used).
When a router removes a link from an oif-list, it must be able to When a router removes a link from an oif-list, it must be able to
reevaluate the values that it will advertise upstream. This happens reevaluate the values that it will advertise upstream. This happens
when an oif-list entry is timed out or a Prune is received. when an oif-list entry is timed out or a Prune is received.
It is recommended that the Join Attribute defined in this draft be It is recommended that the Join Attribute defined in this draft be
used for entries in the join-list part of the Join/Prune message. If used for entries in the join-list part of the Join/Prune message. If
skipping to change at page 11, line 41 skipping to change at page 11, line 41
(where accumulation of new values from subsequent Joins cause re- (where accumulation of new values from subsequent Joins cause re-
population of values and a new max/min/ count can be reevaluated for population of values and a new max/min/ count can be reevaluated for
the route). the route).
It is recommended that when triggered Join/Prune messages are sent by It is recommended that when triggered Join/Prune messages are sent by
a downstream router, that the accounting information not be included a downstream router, that the accounting information not be included
in the message. This way when convergence is important, avoiding the in the message. This way when convergence is important, avoiding the
processing time to build an accounting record in a downstream router processing time to build an accounting record in a downstream router
and processing time to parse the message in the upstream router will and processing time to parse the message in the upstream router will
help reduce convergence time. An upstream router should not help reduce convergence time. An upstream router should not
interpret a Join/Prune message received with no acccounting data to interpret a Join/Prune message received with no accounting data to
mean clearing or resetting what accounting data it has cached. mean clearing or resetting what accounting data it has cached.
7. Caveats 7. Caveats
This draft requires each router on a multicast distribution tree to This draft requires each router on a multicast distribution tree to
support this draft or else the accounting attributes for the tree support this draft or else the accounting attributes for the tree
will not be known. will not be known.
However, if there are a contiguous set of routers downstream in the However, if there are a contiguous set of routers downstream in the
distribution tree, they can maintain accounting information for the distribution tree, they can maintain accounting information for the
sub-tree. sub-tree.
If there are a set of contiguous routers supporting this draft If there are a set of contiguous routers supporting this draft
upstream on the multicast distribution tree, accounting information upstream on the multicast distribution tree, accounting information
will be available but it will not represent an accurate assessment of will be available but it will not represent an accurate assessment of
the entire tree. Also, it will not be clear for how much of the the entire tree. Also, it will not be clear for how much of the
distribution tree the accounting information covers. distribution tree the accounting information covers.
8. IANA Considerations 8. IANA Considerations
A new PIM Hello Option type needs to be assigned. 29 is proposed in A new PIM Hello Option type, 29, has been assigned. See [HELLO] for
this draft. detail.
A new PIM Join Attribute type needs to be assigned. 2 is proposed in A new PIM Join Attribute type needs to be assigned. 2 is proposed in
this draft. this draft.
9. Security Considerations 9. Security Considerations
There are no security considerations for this design other than what There are no security considerations for this design other than what
is already in the main PIM specification [RFC4601]. is already in the main PIM specification [RFC4601].
10. Acknowledgments 10. Acknowledgments
 End of changes. 11 change blocks. 
25 lines changed or deleted 27 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/