One document matched: draft-ietf-pim-hierarchicaljoinattr-08.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>
<rfc category="std" ipr="trust200902" updates="5384"
docName="draft-ietf-pim-hierarchicaljoinattr-08.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>Hierarchical Join/Prune Attributes</title>
<author initials='S.' surname='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 initials='J.' surname='Arango' fullname='Jesus Arango'>
<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>jearango@cisco.com</email></address>
</author>
<author initials='I.' surname='Kouvelas' fullname='Isidor Kouvelas'>
<organization>Arista Networks</organization>
<address>
<postal>
<street>5453 Great America Parkway</street>
<city>Santa Clara</city> <region>CA</region>
<code>95054</code>
<country>USA</country>
</postal>
<email>kouvelas@arista.com</email></address>
</author>
<date/>
<abstract>
<t>This document defines a hierachical method of encoding Join attributes,
providing a more efficient encoding when the same attribute values need
to be specified for multiple sources in a PIM Join/Prune message. This
document updates RFC 5384 by renaming the Encoding Type registry
specified there.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>PIM Join attributes as defined in <xref target="RFC5384"/> allow for
specifying a set of attributes for each of the joined or pruned sources
in a PIM Join/Prune message. Attributes must be separately specified for
each individual source in the message. However, in some cases the same
attributes and values need to be specified for some, or even all, the
sources in the message. The attributes and their values then need to be
repeated for each of the sources where they apply.
</t><t>
This document provides a hierarchical way of encoding attributes and
their values in a Join/Prune message, so that if the same attribute and
value is to apply for all the sources, it needs only be specified once
in the message. Similarly, if all the sources in a specific group set
share a specific attribute and value, it needs only be specified once for
the entire group set.
</t><t>
This document extends <xref target="RFC5384"/> by specifying that the
encoding type defined there also applies to Encoded-Unicast and
Encoded-Group formats. This document also updates RFC 5384 by renaming the
PIM Encoded-Source Address Encoding Type Field registry to be a
PIM Address Encoding Type registry. The content of the registry remains
the same. The encoding type used for Join attributes is however still
limited to be used in Join/Prune messages. Note that Join attributes, as
they are referred to in <xref target="RFC5384"/>, also apply to pruned
sources in a Join/Prune message. Thus the more correct name Join/Prune
attributes will be used throughout the rest of this document.
</t><t>
This document allows Join/Prune attributes to be specified in the
Upstream Neighbor Address field, and also in the Multicast Group Address
field, of a Join/Prune message. It defines how this is used to specify
the same Join/Prune attribute and value for multiple sources.
This document also defines a new Hello Option to indicate support for
the hierarchical encoding specified.</t>
</section>
<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="Hierarchical Join/Prune Attribute Definition">
<t>The format of a PIM Join/Prune message is defined in
<xref target="RFC7761"/> as follows:</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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PIM Ver| Type | Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Upstream Neighbor Address (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Num groups | Holdtime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Group Address 1 (Encoded-Group format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Joined Sources | Number of Pruned Sources |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Joined Source Address 1 (Encoded-Source format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Joined Source Address n (Encoded-Source format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pruned Source Address 1 (Encoded-Source format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pruned Source Address n (Encoded-Source format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Group Address m (Encoded-Group format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Joined Sources | Number of Pruned Sources |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Joined Source Address 1 (Encoded-Source format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Joined Source Address n (Encoded-Source format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pruned Source Address 1 (Encoded-Source format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pruned Source Address n (Encoded-Source format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
<postamble />
</figure>
<t>The message contains a single Upstream Neighbor Address, and
one or more group sets. Each group set contains a Group Address
and two source lists, the Joined Sources and the Pruned Sources.
The Upstream Neighbor Address, the group addresses and the source
addresses are encoded in Encoded-Unicast format, Encoded-Group
format and Encoded-Source format, respectively. This document extends
the use of the source address encoding defined in <xref target="RFC5384"/>
to also apply to the Upstream Neighbor Address and the Group Address
fields, see <xref target="encoding"/>.
</t><t>
For a Join/Prune message a hierarchy of Join/Prune attributes is defined.
Attributes at the highest level, that is the least specific, apply to
every source in the message. These are encoded in the Upstream Neighbor
Address. Attributes at the next more specific level apply to every source
in a group set. They are encoded in a Group Address. And finally there
are attributes that apply to a single source, encoded in the source
address as defined in <xref target="RFC5384"/>.</t>
<t>The complete set of attributes that apply to a given source is
obtained by combining the message wide attributes, the attributes
of the group set that the source belongs to, and the source
specific attributes. However, if the same attribute is specified at
multiple levels, then the one at the most specific level overrides
the other instances of the attribute. Note that the set of attributes
and their values is formed before processing the attributes. Hence
a value that is invalid for a given type might override a valid
value at a higher level.</t>
<t>As an example, say that for a given source we have attributes
T_1 with value V_1, T_2 with value V_2, and T_3 with value V_3. Also
that in the Group Address of the source's group set we have attributes
T_1 with value V_6, and T_4 with value V_4. And that we in the Upstream
Neighbor Address have encoded the attributes T_1 with value V_7, T_4 with
value V_8, and T_5 with value V_5. The attributes applied to the given
source will be T_1 with value V_1, T_2 with value V_2, T_3 with value V_3,
T_4 with value V_4 and T_5 with value V_5. Here we have T_1 with different
values at each level, so we use the value specified at the source level.
Also we have T_4 with different values at the group and message levels,
so we use the value at the group level. Here it could be that V_1 is
not a valid value for T_1, but it still overrides the values at the
higher levels as we do not process the attributes until after forming
the set.
</t>
<t>Note that Join/Prune attributes are still applied to sources as
specified in <xref target="RFC5384"/>. This document does not change
the meaning of any attributes, it is simply a more compact way of
encoding an attribute when the same attribute and value applies to
multiple sources. E.g., with the example above, we would have the
exact same meaning if we instead had encoded all the attributes
T1, ..., T5 with the respective values V1, ..., V5 in the source
address.</t>
</section>
<section title="PIM Address Encoding Types" anchor="encoding">
<t>Addresses in PIM messages are specified together with an address family
and an encoding type. This applies to Encoded-Unicast, Encoded-Group and
Encoded-Source addresses. The encoding types allow the address to be
encoded according to different schemes. An encoding type indicates how
an address is encoded irrespective of address type, Encoded-Unicast,
Encoded-Group or Encoded-Source. It is possible that there will be
future encoding types that do not apply to all address types though.
This means that as currently defined, 0 is native encoding, and 1 is
Join/Prune attributes encoding, encoded according to
<xref target="RFC5384"/>. Note that as specified in
<xref target="RFC5384"/>, a type 1 Encoded Address MUST contain at least
one Join/Prune attribute.
</t>
</section>
<section title="Hierarchical Join/Prune Attribute Hello Option">
<t>A PIM router indicates that it supports the mechanism specified
in this document by including the Hierarchical Join/Prune Attribute
Hello Option in its PIM Hello message. When this new Hello Option
is included, it MUST also include the Join-Attribute Hello option as
specified in <xref target="RFC5384"/>. The format of the
Hierarchical Join/Prune Attribute 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 = TBD | OptionLength = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
<postamble />
</figure>
<t>OptionType = TBD, OptionLength = 0. Note that there is no
option value included.</t>
<t>A PIM router MUST NOT send a Join/Prune message with
Join/Prune attributes encoded in the Upstream Neighbor Address
or any of the group addresses out any interface on which there is a
PIM neighbor that has not included this option in its Hellos. Even
a router that is not the upstream neighbor must be able to parse the
message in order to perform Join suppression and Prune override.</t>
</section>
<section title="Security Considerations">
<t>This document specifies a more compact encoding of Join/Prune
attributes. Use of the encoding has no impact on security aside
from using the encoding in <xref target="RFC5384"/>. For instance
an attack with a forged message with certain attribute values is
equally difficult independent of which encoding is used. If an
attribute that applies to the entire message is wrong, then that
may cause an issue for all the sources in the message. But without
this encoding, one would instead include that attribute for every
single source, and that would also cause an issue for all the
sources in the message.
</t>
</section>
<section title="IANA Considerations">
<t>The current PIM Encoded-Source Address Encoding Type Field registry
needs to be renamed to a PIM Address Encoding Type registry. The content
of the registry remains the same. The Hierarchical Join/Prune Attribute
Hello Option needs to be added to the PIM-Hello Options registry, and
TBD above must be replaced by the assigned value.
</t>
</section>
</middle>
<back>
<references title='Normative References'>
<?rfc include='reference.RFC.2119' ?>
<?rfc include='reference.RFC.5384' ?>
<?rfc include='reference.RFC.7761' ?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 05:22:59 |