One document matched: draft-ietf-pim-hierarchicaljoinattr-01.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-01.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='I.' surname='Kouvelas' fullname='Isidor Kouvelas'>
<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>kouvelas@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>
<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.</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 updates <xref target="RFC5384"/> which
defines an encoding to be used for Encoded-Source Addresses. This document
extends this by specifying the same encoding type also for
Encoded-Unicast and Encoded-Group formats. This document defines a new
IANA registry for PIM encoding types which is to be used for all
the fields in PIM messages where encoding types are used, replacing the old
registry that is specific to Encoded-Source Addresses. 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 Join/Prune attribute to further control
the scope of hierarchical attributes, as well as 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="RFC4601"/> 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 all encoded in Encoded-Unicast format, Encoded-Group
format and Encoded-Source format, respectively. In this document we
make use of this to allow Join/Prune attributes in each of these
addresses, using the encoding in <xref target="encoding"/>.
</t><t>
For a Join/Prune message we define a hierarchy of Join/Prune attributes.
At the highest level, that is the least
specific, we have attributes that apply to every source in the message.
These are encoded in the Upstream Neighbor Address. At the next more
specific level we have attributes that apply to every source in a group
set. They are encoded in a Group Address. And finally at the
most specific level, we have attributes that just 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.</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.</t>
</section>
<section title="Do Not Inherit (DNH) Join/Prune Attribute">
<t>When considering the attributes for a specific source we inherit
attributes from higher up in the hierarchy. As described above, if an
attribute is specified at multiple levels, the one at the most specific
level overrides the other instances of the attribute. However, we also
want to be able to ignore attributes rather than overriding them.
For instance if a given attribute and value should be specified for all
sources but one, the attribute can be encoded in the Upstream Neighbor
Address, but we need a way to specify that for the one source the attribute
should not be applied. We do this by defining a new attribute called
Do Not Inherit (DNH) that lists attribute types that should not be
inherited from the less specific levels of the hierarchy. For the one
source we add the DNH attribute specifying that the one attribute type
should be ignored if present at the message wide or at the group level.
Similarly the DNH attribute can be used at the group level to ignore
certain attributes specifed at the message wide level. If an attribute
is ignored at a level, it can again be specified where needed at
more specific levels.</t>
<t>Do Not Inherit Attribute Format</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|S| Attr Type | Length | Ignore Type 1 | Ignore Type 2 |...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
]]></artwork>
<postamble />
</figure>
<t>F-bit (transitive) MUST be set to 0. This attribute MUST not be
transitive. A router receiving a message using hierarchical
attributes would decide whether this attribute is needed for
efficient encoding and where when formatting a Join/Prune to send
upstream, and this is independent of how a received Join/Prune was
formatted.</t>
<t>E-bit (end of attributes) is set according to whether it is the
last encoded attribute, see xref target="RFC5384"/>.</t>
<t>Attr Type = TBD1 is the type identifying this attribute.</t>
<t>Length denotes the length of the value field in octets.</t>
<t>The value field of the attribute consists of a list of attributes
to not inherit. Each octet specifies one attribute type.</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. While it is possible to have the
same encoding type value indicate different encodings depending on whether
it is a Unicast, Group or Source address, it is simpler to have the same
encoding type value indicate the same encoding independent of where it is
used. This means that as currently defined, 0 means a native encoding,
and 1 means there are Join/Prune attributes, encoded according to
<xref target="RFC5384"/>. Even if the encoding type space is shared
between the different address types (Encoded-Unicast, Encoded-Group and
Encoded-Source), one could have a specific encoding apply to a specific
address type if needed.</t>
<t>The current IANA PIM Encoded-Source Address Encoding Type Field registry
should be changed into a PIM Address Encoding Type registry.</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. Note that it also needs to
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 = TBD2 | OptionLength = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
<postamble />
</figure>
<t>OptionType = TBD2, 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 do Join suppression or Prune overriding.</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.
</t>
</section>
<section title="IANA Considerations">
<t>The current PIM Encoded-Source Address Encoding Type Field registry
should be changed into a PIM Address Encoding Type registry. The only
required change is the name of the registry. The contents remain the
same.</t>
<t>An assignment is needed from the Join attribute registry for the
Do Not Inherit attribute. The string TBD1 needs to be replaced with
the assigned value.</t>
<t>A new PIM Hello Option type needs to be assigned. The string TBD2
needs to be replaced with the permanently assigned value.</t>
</section>
<section title="Acknowledgments">
<t>The authors would like to thank Siva Kollipara for providing
feedback on the document.</t>
</section>
</middle>
<back>
<references title='Normative References'>
<?rfc include='reference.RFC.2119' ?>
<?rfc include='reference.RFC.4601' ?>
<?rfc include='reference.RFC.5384' ?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 05:23:00 |