One document matched: draft-ietf-pim-pop-count-07.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc4601 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4601.xml'>
<!ENTITY rfc5015 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5015.xml'>
<!ENTITY rfc5384 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5384.xml'>
]>
<rfc category="exp" ipr="trust200902" docName="draft-ietf-pim-pop-count-07.txt">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<front>
<title>Population Count Extensions to PIM</title>
<author surname="Dino Farinacci" fullname='Dino Farinacci'>
<organization>Cisco Systems</organization>
<address><postal>
<street>Tasman Drive</street>
<city>San Jose</city> <region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<email>dino@cisco.com</email></address>
</author>
<author surname="Greg Shepherd" fullname='Greg Shepherd'>
<organization>Cisco Systems</organization>
<address><postal>
<street>Tasman Drive</street>
<city>San Jose</city> <region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<email>gjshep@gmail.com</email></address>
</author>
<author surname='Stig Venaas' fullname='Stig Venaas'>
<organization>Cisco Systems</organization>
<address><postal>
<street>Tasman Drive</street>
<city>San Jose</city> <region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<email>stig@cisco.com</email></address>
</author>
<author surname="Yiqun Cai" fullname='Yiqun Cai'>
<organization>Microsoft</organization>
<address><postal>
<street>1065 La Avenida</street>
<city>Mountain View</city> <region>CA</region>
<code>94043</code>
<country>USA</country>
</postal>
<email>yiqunc@microsoft.com</email></address>
</author>
<date/>
<abstract>
<t>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.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>This document specifies a mechanism to convey accounting
information using the PIM protocol <xref target="RFC4601"/>
<xref target="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.</t>
<t>This mechanism 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.</t>
<t>The sort of accounting data this specification provides, on a
per multicast route basis, are:</t>
<t><list style="numbers">
<t>The number of branches in a distribution tree.</t>
<t>The membership type of the distribution tree, that is
Source-Specific Multicast (SSM) or Any-Source Multicast (ASM).</t>
<t>Routing domain and time zone boundary information.</t>
<t>On-tree node and tree diameter counters.</t>
<t>Effective MTU and bandwidth.</t>
</list></t>
<t>This document defines a new PIM Join Attribute type
<xref target="RFC5384"/> to the
Join/Prune message as well as a new Hello option. The mechanism is
applicable to IPv4 and IPv6 multicast. </t>
<t>This is a new extension to PIM, and it is not completely
understood what impact collecting information using PIM
would have on the operation of PIM. This is an entirely new
concept. Many PIM features (including the core protocols) were
first introduced as Experimental RFCs, and it seems appropriate
to advance this work as Experimental. Reports of implementation
and deployment across whole distribution trees or within sub-trees
(see <xref target="caveats"/>) will enable an assessment of the
desirability and stability of this specification. The PIM working
group will then consider whether to move this work to the Standards
Track.</t>
<t>This document does not specify how an administrator or user
can access this information. It is expected that an implementation
may have a command line interface or other ways of requesting
and displaying this information. As this is currently an
Experimental document, defining a MIB module has not been
considered. If the PIM working group finds that this should move
on to Standards Track, a MIB module should be considered.</t>
<section title="Requirements Notation">
<t>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 <xref target="RFC2119"/>.</t>
</section>
<section title="Terminology">
<t>This section defines the terms used in this document.</t>
<t><list style="hanging">
<t hangText="Multicast Route: ">A (S,G) or (*,G) entry regardless
if the route is in ASM, SSM, or Bidir mode of operation.</t>
<t hangText="Stub Link: ">A link with members joined to the
group via IGMP or Multicast Listener Discovery (MLD)</t>
<t hangText="Transit Link: ">A link put in the oif-list
(outgoing interface list) for a multicast route because it was
joined by PIM routers.</t>
</list></t>
<t>Note that a link can be both a Stub Link and a Transit
Link at the same time.</t>
</section>
</section>
<section title="Pop-Count-Supported Hello Option">
<t>A PIM router indicates that it supports the mechanism specified
in this document by including the Pop-Count-Supported Hello option
in its PIM Hello message. Note that it also needs to include the
Join-Attribute Hello option as specified in
<xref target="RFC5384"/>. The format of the Pop-Count-Supported
Hello option is defined to be:</t>
<figure>
<preamble></preamble>
<artwork><![CDATA[
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
<postamble />
</figure>
<t>OptionType = TBD1, OptionLength = 0. Note that there is no
option value included. In order to allow future updates of
this specification that may include an option value,
implementations of this document MUST accept and process this
option also if the length is non-zero. Implementations of this
specification MUST accept and process the option ignoring any
option value that may be included.</t>
</section>
<section title="New Pop-Count Join Attribute Format">
<t>When a PIM router supports this mechanism and has determined
from a received Hello, that the neighbor supports this mechanism,
and also that all the neighbors on the interface support the use
of join attributes, it will send Join/Prune messages that MAY
include a Pop-Count Join Attribute. The
mechanism to process a PIM Join Attribute is described in
<xref target="RFC5384"/>. The format of the new attribute is
specified in the following. </t>
<figure>
<preamble></preamble>
<artwork><![CDATA[
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 |
. . .
. . .
. . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
<postamble />
</figure>
<t>The above format is used only for entries in the join-list
section of the Join/Prune message.</t>
<t><list style="hanging">
<t hangText="F bit: ">0 Non-Transitive Attribute. </t>
<t hangText="E bit: ">As specified by
<xref target="RFC5384"/>. </t>
<t hangText="Attr Type: ">TBD2. </t>
<t hangText="Length: ">The minimum length is 6. </t>
<t hangText="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. </t>
<t>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.</t>
<t hangText="Flags: ">The flags field has the following
format:
<figure>
<preamble></preamble>
<artwork><![CDATA[
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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
<postamble />
</figure></t>
<t><list style="hanging">
<t hangText="Unallocated/Reserved Flags: ">The flags which are
currently
not defined. If a new flag is defined and used by a new
implementation, an old implementation should preserve the bit
settings. This means that a router MUST preserve the settings of
all Unallocated/Reserved Flags in PIM Join messages received from
downstream routers in any PIM Join sent upstream.</t>
<t hangText="S flag: ">If an IGMPv3 or MLDv2 report with an
INCLUDE Mode group record 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.</t>
<t hangText="A flag: ">If an IGMPv3 or MLDv2 report with an
EXCLUDE Mode group record, or 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.</t>
<t>A combination of settings for these bits indicate:
<figure>
<preamble></preamble>
<artwork><![CDATA[
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 using SSM
1 0 All group members are using ASM
1 1 A mixture of SSM and ASM group members
]]></artwork>
<postamble />
</figure></t>
<t hangText="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.</t>
<t hangText="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 <xref target="I-D.ietf-mboned-auto-multicast"/>
protocol.</t>
<t hangText="P flag: ">This flag is set by a router if all
downstream routers support this specification. That is, they
are all PIM pop-count capable. If a downstream router does not
support this specification it MUST be cleared. This allows one
to tell if the entire sub-tree is completely accounting
capable.</t>
</list></t>
<t hangText="Options Bitmap: ">This is a bitmap that
shows which options are present. The format of the
bitmap is as follows:
<figure>
<preamble></preamble>
<artwork><![CDATA[
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
<postamble />
</figure>
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:
<figure>
<preamble></preamble>
<artwork><![CDATA[
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
]]></artwork>
<postamble />
</figure>
See <xref target="options"/> 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.</t>
<t>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.</t>
<t hangText="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 <xref target="options"/>
for details on the options defined in this document.</t>
</list></t>
<section title="Options" anchor="options">
<t>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. Note that there is no alignment requirements for
the options, so an implementation cannot assume they are aligned.
<list style="hanging">
<t hangText="Transit Oif-List Count: ">This is filled in by a
router sending a Join/Prune message indicating the number of
transit links on the multicast distribution tree. The value
is the number of oifs (outgoing interfaces) for the multicast
route that have been joined by PIM plus the sum of the values
advertised by each of the downstream PIM routers that have
joined on this oif. Length 4 octets.</t>
<t hangText="Stub Oif-List Count: ">This is filled in by a
router sending a Join/Prune message indicating the number of
stub links (links where there are host members) on the
multicast distribution tree. The value is the number of
of oifs for the multicast route that have been joined
by IGMP or MLD plus the sum of the values advertised by each of
the downstream PIM routers that have joined on this oif.
Length 4 octets.</t>
<t hangText="Minimum Speed Link: ">This contains the minimum
bandwidth rate for any link in the oif-list and is encoded
as specified in <xref target="speedenc"/>. 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 smallest
value 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.</t>
<t hangText="Maximum Speed Link: ">This contains the maximum
bandwidth rate for any link in the oif-list and is encoded
as specified in <xref target="speedenc"/>. 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
largest value 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
speed link for the multicast distribution tree.
Length 2 octets.</t>
<t hangText="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. For this to work, an implementation needs a way
of knowing that a neighbor or an interface is in a different
domain. There is no standard way of doing this.
Length 1 octet.</t>
<t hangText="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.</t>
<t hangText="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.</t>
<t hangText="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.</t>
</list></t>
<section title="Link Speed Encoding" anchor="speedenc">
<t>The speed is encoded using 2 octets as follows:
<figure>
<preamble></preamble>
<artwork><![CDATA[
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Exponent | Significand |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
<postamble />
</figure>
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.</t>
<t>Here are some examples how this is used:
<figure>
<preamble></preamble>
<artwork><![CDATA[
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
]]></artwork>
<postamble />
</figure>
</t>
</section>
</section>
<section title="Example message layouts">
<t>We will here give a few examples to illustrate the
use of flags and options.</t>
<t>A minimum size message has no option flags set, and looks
like this:
<figure>
<preamble></preamble>
<artwork><![CDATA[
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
<postamble />
</figure>
</t>
<t>A message containing all the options defined in this
document would look like this:
<figure>
<preamble></preamble>
<artwork><![CDATA[
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 = 18 | Effective MTU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unalloc/Reserved |P|a|t|A|S|1|1|1|1|1|1|1|1| Unalloc/Rsrvd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transit Oif-List Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stub Oif-List Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum Speed Link | Maximum Speed Link |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Domain Count | Node Count | Diameter Count| TZ Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
<postamble />
</figure>
</t>
<t>A message containing only Stub Oif-List Count and
Node Count would look like this:
<figure>
<preamble></preamble>
<artwork><![CDATA[
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 = 9 | Effective MTU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unalloc/Reserved |P|a|t|A|S|0|1|0|0|0|1|0|0| Unalloc/Rsrvd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stub Oif-List Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Node count |
+-+-+-+-+-+-+-+-+
]]></artwork>
<postamble />
</figure>
</t>
</section>
</section>
<section title="How to use Pop-Count Encoding">
<t>A router supporting this mechanism MUST, unless
administratively disabled, include the PIM Join
Attribute option in its PIM Hellos. See <xref target="RFC5384"/>
and <xref target="HELLO"/> for details.</t>
<t>It is RECOMMENDED that implementations allow for administrative
control whether to make use of this mechanism. Implementations
MAY also allow further control of what information to store and
send upstream.</t>
<t>It is very important to note that any changes to the values
maintained by this mechanism MUST NOT trigger a new Join/Prune
message. Due to the periodic nature of PIM, the values can be
accurately obtained at 1 minute intervals (or whatever
Join/Prune interval used).</t>
<t>When a router removes a link from an oif-list, it need to be
able to reevaluate the values that it will advertise upstream.
This happens when an oif-list entry is timed out or a Prune is
received.</t>
<t>It is RECOMMENDED that the Join Attribute defined in
this document be used only for entries in the join-list part of
the Join/Prune message. If the attribute is used in the
prune-list, an implementation MUST ignore it and process the
Prune as if the attribute was not present.</t>
<t>It is also RECOMMENDED that join suppression be disabled
on a LAN when Pop-Count is used.</t>
<t>It is RECOMMENDED that when triggered Join/Prune messages
are sent by a downstream router, that the accounting information
not be included in the message. This way when convergence is
important, avoiding the processing time to build an accounting
record in a downstream router and processing time to parse the
message in the upstream router will help reduce convergence time.
An upstream router SHOULD NOT interpret a
Join/Prune message received with no accounting data to mean
clearing or resetting what accounting data it has cached.</t>
</section>
<section title="Implementation Approaches">
<t>This section offers some non-normative suggestions for how
pop-count may be be implemented.</t>
<t>An implementation can decide how the accounting attributes are
maintained. The values can be stored as part of the multicast
route data structure by combining the local information it has
with the joined information on a per oif basis. So when
it is time to send a Join/Prune message, the values stored
in the multicast route can be copied to the message.</t>
<t>Or, an implementation could store the accounting values per
oif and when a Join/Prune message is sent, it can combine the
oifs with its local information. Then the combined information
can be copied to the message.</t>
<t>When a downstream joiner stops joining, accounting values
cached must be evaluated. There are two approaches which
can be taken. One is to keep values learned from each joiner
so when the joiner goes away the count/max/min values are
known and the combined value can be adjusted. The other
approach is to set the value to 0 for the oif, and then start
accumulating new values as subsequent Joins are received.</t>
<t>The same issue arises when an oif is removed from the oif-list.
Keeping per-oif values allows you to adjust the per-route values
when an oif goes away. Or, alternatively, a delay for
reporting the new set a values from the route can occur
while all oif values are zeroed (where accumulation of new
values from subsequent Joins cause re-population of values and
a new max/min/count can be reevaluated for the route).</t>
</section>
<section title="Caveats" anchor="caveats">
<t>This specification requires each router on a multicast
distribution tree to support this specification or else the
accounting attributes for the tree will not be known.</t>
<t>However, if there are a contiguous set of routers downstream
in the distribution tree, they can maintain accounting
information for the sub-tree.</t>
<t>If there are a set of contiguous routers supporting this
specification upstream on the multicast distribution tree,
accounting information 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 distribution tree
the accounting information covers.</t>
</section>
<section title="IANA Considerations">
<t>A new PIM Hello Option type, 29, has been assigned
temporarily. The string TBD1 needs to be replaced with the
permanently assigned value. See
<xref target="HELLO"/> for details. Although the length is
specified as 0 in this specifications, non-zero length is
allowed, so IANA should list the length as being variable.</t>
<t>A new PIM Join Attribute type needs to be assigned. The
string TBD2 needs to be replaced with the assigned value.</t>
</section>
<section title="Security Considerations">
<t>The use of this specification requires some additional
processing of PIM Join/Prune messages. However, the additional
amount of processing is fairly limited, so this is not believed
to be a significant concern.</t>
<t>The use of this mechanism includes information like the
number of receivers. This information is assumed to not be
of sensitive nature. If an operator has concerns about revealing
this information to upstream routers, or other routers/hosts that
may potentially inspect this information, there should be a way
to disable the mechanism, or alternatively more detailed control
of what information to include.</t>
</section>
<section title="Acknowledgments">
<t>The authors would like to thank John Zwiebel, Amit Jain, and
Clayton Wagar for their review comments on the initial versions
of this document. Adrian Farrel did a detailed review of the
document and proposed textual changes that have been
incorporated. Further review and comments were provided by
Thomas Morin and Zhaohui (Jeffrey) Zhang.</t>
</section>
</middle>
<back>
<references title='Normative References'>
&rfc2119;
&rfc4601;
&rfc5015;
&rfc5384;
</references>
<references title='Informative References'>
<reference anchor="HELLO">
<front>
<title>PIM-Hello Options</title>
<author surname="IANA">
<organization />
</author>
<date/>
</front>
<seriesInfo name=""
value="<http://www.iana.org/assignments/pim-parameters>"/>
</reference>
<?rfc include='reference.I-D.ietf-mboned-auto-multicast' ?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 05:10:59 |