RFC 5384

The Protocol Independent Multicast (PIM) Join Attribute Format 🎀

okay bestie, the title block is the tea ☕ This is RFC 5384 ✨. It's a Standards Track doc from A. Boers, I. Wijnands, and E. Rosen, all at Cisco Systems, Inc. It came out in November 2008 🍓. The header doesn't list anything it obsoletes or updates, so it's standing on its own 💅

Status of This Memo 📜

This document is an Internet standards track protocol spec for the Internet community, and it's asking for discussion and suggestions for improvements 🫶 If you want to know where it stands in terms of standardization, check the current edition of the "Internet Official Protocol Standards" (STD 1) 👑 Distribution is totally unlimited, so go share it 🦋

Copyright Notice ©️

Copyright (c) 2008 IETF Trust and the people listed as the document authors. All rights reserved 💜

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info), as they stand on the date it was published. Please actually read them, bestie, because they explain your rights and restrictions for this document 🙈

Abstract ✨

So, a "Protocol Independent Multicast - Sparse Mode" Join message from a node lists one or more multicast distribution trees that the node wants to join 🌳 Each tree is identified by a multicast group address together with a source address, and that source address can be a "wild card" 🃏 In some situations, when you're joining a tree, it helps to include extra info about how the tree gets built. Until now there was no way to do that 😭 This document changes the Join message so a node can attach attributes to a specific tree. The attributes are encoded in Type-Length-Value format 🧚

Table of Contents 📚

   1. Introduction ....................................................2
   2. Specification of Requirements ...................................3
   3. Use of Join Attributes ..........................................3
      3.1. Sending Join Attributes ....................................3
      3.2. The Join Attribute Option in the PIM Hello .................4
      3.3. Receiving Join Attributes ..................................4
           3.3.1. General Considerations ..............................4
           3.3.2. Transitive and Non-Transitive Attributes ............5
           3.3.3. Conflicting Attributes ..............................5
           3.3.4. Attribute Change ....................................6
      3.4. PIM Attribute Packet Format ................................7
           3.4.1. PIM Join Packet Format ..............................7
           3.4.2. PIM Join Attribute Hello Option .....................8
   4. IANA Considerations .............................................8
   5. Security Considerations .........................................9
   6. Acknowledgments .................................................9
   7. Normative References ............................................9
   8. Informative References ..........................................9

1. Introduction 🌸

Okay so, in the protocol called "Protocol Independent Multicast - Sparse Mode" [RFC4601] (aka "PIM" from here on), a node can send a Join message that names one or more multicast distribution trees it wants to join 🦋 Each tree is identified by a group address plus a source address, and the source can be a "wild card" 🃏 Sometimes it's really useful to pass extra info when you join, something about how the tree should be built. We haven't had a way to do that until now 😤 This document tweaks the Join message so a node can attach an attribute to a particular tree it's joining. That attribute is encoded as Type-Length-Value (TLV) format, and these are called "PIM Join Attributes" 💅

In the PIM Join message, the Source Address is carried as an "Encoded-Source Address" ([RFC4601], section 4.9.1). Every Encoded-Source Address goes with a particular group address, which is written as an "Encoded-Group Address" 💖 Put the two together and you've got a multicast distribution tree 🌳 The Encoded-Source Address has an "encoding type" field, and the only value [RFC4601] defines is 0. This spec is the first one to give a different encoding type value a meaning 🧚

So to attach TLVs to a tree, this spec makes a brand new encoding type for the Encoded-Source Address: type 1 ✨ When type 1 is used, the Encoded-Source Address can hold a list of Join Attributes, and each one is a TLV 🎀 The type 1 Encoded-Source Address, together with its Encoded-Group Address, picks out the tree, and the Join Attribute TLVs say which attributes apply to it 🫶 Other than having Join Attributes inside, a type 1 Encoded-Source Address works exactly like a type 0 one 💅

This document doesn't define any specific Join Attribute. What it does do is explain how Join Attributes get encoded into Join messages, plus the generic procedures every Join Attribute shares 🌈 What any particular attribute actually does is outside what this doc covers 🙈

The use of Join Attributes in "Protocol Independent Multicast - Dense Mode" [RFC3973] isn't considered here 🫠

2. Specification of Requirements 📋

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] 💜

3. Use of Join Attributes 🎀

3.1. Sending Join Attributes 🚀

Join Attributes get encoded as TLVs right into the Encoded-Source Address field of a PIM Join message, which is covered in section 3.4.1 below 🧚 Every attribute applies to the same multicast distribution tree, the one identified by the Encoded-Source Address together with its associated Encoded-Group Address 🌳 That tree can be source-specific or a shared tree, either one works ✨

The way the "source address" field is encoded inside the Encoded-Source Address is exactly the same for type 1 as it is for type 0, as specified in [RFC4601] 💅

A type 1 Encoded-Source Address MUST contain at least one Join Attribute. If you want to say a tree has no Join Attributes, you just use the type 0 Encoded-Source Address instead 🫶

You can have several Join Attributes of the same type or of different types inside a single Encoded-Source Address 🌈 This spec doesn't require all the attributes of one type to sit next to each other 💖 There's no header field that tells you how many attributes there are. Instead, the last attribute gets specially marked as the last one 🙌

Now here's the spicy part 🌶️ Any PIM router that doesn't understand the type 1 Encoded-Source Address won't be able to process a PIM Join message containing one 💀 And if a particular Join Attribute changes how the multicast distribution tree gets built, the tree might not come together correctly unless every PIM router that receives the attribute understands it 😬 So attributes are really only useful inside a single administrative domain, or maybe a small set of neighboring cooperating domains, where you can be sure ahead of time that every deployed PIM router understands the type 1 Encoded-Source Address and whatever specific attributes are in use 🔥

3.2. The Join Attribute Option in the PIM Hello 👋

To make sure a type 1 Encoded-Source Address never gets sent to a PIM neighbor that can't read that encoding, this spec adds a new PIM Hello option called the "Join Attribute" option 🛡️ This option MUST be included in the PIM Hellos of any PIM router that's willing to receive type 1 Encoded-Source Addresses. A PIM router MUST NOT send a type 1 Encoded-Source Address out of any interface where there's a PIM neighbor that hasn't included this option in its Hellos. (Even a router that isn't the upstream neighbor still has to be able to parse the packet, so it can do Join suppression or overriding 👀)

Heads up, though: a PIM router that sends the "Join Attribute" Hello option doesn't necessarily understand every possible attribute type 🫠 Since there's no quick way to act on a neighbor not being able to process certain attribute types, the spec doesn't want a separate Hello option for every possible attribute type 🙅‍♀️

3.3. Receiving Join Attributes 📥

3.3.1. General Considerations 🧠

A PIM router that receives a type 1 Encoded-Source Address MUST examine all the attributes in the order they appear 👀

The specification for a given attribute type MUST specify the procedure to apply when there are multiple instances of that attribute type 📜

Processing an attribute can affect the following:

• the construction of the associated multicast distribution tree,
• the processing of other attributes of the same type that also appear in the type 1 Encoded-Source Address, and
• the forwarding (or not) of the attribute itself and/or other attributes of the same type that also appear in the type 1 Encoded-Source Address.

If processing a received attribute has any effect on how the multicast distribution tree gets constructed, or on which attributes get forwarded up the tree, then state MUST be maintained that associates the received attribute with the adjacency or adjacencies it came in from 🗂️

3.3.2. Transitive and Non-Transitive Attributes 🔁

If a PIM router understands a particular attribute type, the attribute gets processed the way described above ✨

If a PIM router doesn't understand the type of a particular attribute, the router either forwards that attribute or discards it, depending on how the attribute's F-bit is set 🤷‍♀️ If the F-bit is set, the router MUST forward the attribute. If the F-bit is clear, the router MUST discard it 💅

If one or more non-transitive attributes get discarded, the rest of the Join Attributes (if there are any) still get forwarded 🫶 And if there are no Join Attributes left to forward, a Join with a type 0 Encoded-Source Address field MUST be forwarded 🦋

3.3.3. Conflicting Attributes ✨

okay so it's totally possible for a router to get conflicting attribute info from different downstream routers 😭 But conflicts only happen between attributes of the same type 🎀

       ( Edge A1 )            ( Edge B1 )---- [R1]
      /           \          /
     /             \        /
   [S]              ( Core )
     \             /        \
      \           /          \
       ( Edge A2 )            ( Edge B2 )---- [R2]

                                 Figure 1

picture Figure 1 and say a Join Attribute is being used to pick an exit router 🦋 There are 2 receivers for the same group, hanging off Edge B1 and Edge B2. Edge B1 prefers A1 as its exit to reach the source S, and B2 prefers A2. If both B1 and B2 send a Join with an attribute saying "prefer my exit router" and they both cross the same core router, that core router is gonna get conflicting info for the source 💀 When that happens, we use the attribute from the PIM adjacency with the numerically smallest IP address. For IPv6, the link local address is what counts 🧚 And if two neighbors have the same IP address (IPv4 or IPv6, doesn't matter), the interface index MUST be used as the tie breaker 👑

The attributes from the other sending routers MAY be remembered 💜 Why? Bc if the adjacency that gave us the winning attribute gets pruned or expires, we can immediately switch to the attribute from the next one in line of preference. No waiting for the next periodic update! we converge fast 🔥

When a particular attribute type is specified, that specification MAY include its own conflict resolution procedure 🌸 If it does, that type-specific procedure MUST be used instead of the procedure described in this section. so the general rule is the backup plan, not the boss 💅

Now the transitive bit: a router might get transitive attributes of a given type from two different adjacencies 🫶 If the router doesn't understand attributes of that type, AND the two adjacencies didn't send the exact same set of attributes of that type, then the conflict resolution procedure in this section MUST be applied to them. Two adjacencies count as having sent the exact same set if they sent the same number of instances of that attribute AND the corresponding instances are byte-for-byte identical. so yes, byte-for-byte, no vibes-based matching 🙈

3.3.4. Attribute Change 🦋

a PIM router might decide to change the set of attributes it has attached to a multicast distribution tree 🌈 This can happen because one of its downstream neighbors on the tree changed its set, or because of processing the attributes. It can also happen for reasons outside this spec, like a config change ⭐

If a PIM router needs to change the attribute set for a tree but its upstream neighbor for that tree stays the same, it MUST send a new Join for that tree, carrying the new set of attributes. And if the new set is the null set, the type 0 Encoded-Source format MUST be used 💖

If a PIM router needs to change the attribute set for a tree AND that change means it switches its upstream neighbor for that tree, then it sends a Prune to the old upstream neighbor. The Prune doesn't need to carry any attributes 🍓

When a PIM router gets a Join for a tree and the Join does NOT contain exactly the same set of attributes as the prior Join, the new Join's set becomes the entire new set. Nothing from the prior Join is kept 😭 There's no way to send incremental changes to the set, so any attribute that's no longer there is considered withdrawn, period 💅 If, after getting a Join, a PIM router figures out the set changed, it'll need to send a new Join upstream with the new set. (Of course, any attribute conflicts may need to be resolved first, obvi 🙄)

And when a PIM router R1 gets a Prune for a tree from a downstream neighbor R2, where R2 had previously sent attributes for that tree, those attributes are considered withdrawn 🥺 Depending on what R1 has from its other downstream neighbors (if any) on that tree, R1 may find the set changed. If so, it needs to send a new Join, with the new attribute set, to its upstream neighbor on the tree 🎀

3.4. PIM Attribute Packet Format 🧚

3.4.1. PIM Join Packet Format 💖

there's no room in the default PIM source encoding for an attribute field, so we introduce a new source encoding type ✨ The attributes are formatted as TLVs. The new Encoded-Source Address 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Addr Family   | Encoding Type | Rsrvd   |S|W|R|  Mask Len     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               Source Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.....
|F|E| Attr_Type | Length        | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.....
|F|E| Attr_Type | Length        | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.....
     .                    .                     .
     .                    .                     .

here's what the bits and bobs mean 👑

• Encoding Type: 1 🌸
• F-bit, Transitive Attribute. If this bit is set, the attribute is a transitive attribute; otherwise, it's non-transitive. See section 3.3.2. 🦋
• E-bit, End of Attributes. If this bit is set, then this is the last Join Attribute in this Encoded-Source Address field. 🫶
• "Attr_Type", a 6-bit field identifying the type of the Attribute. 🍓
• Length field, a 1-octet field giving the length in octets (unsigned binary integer) of the value field. 🌈

The other fields are the same as described in [RFC4601]. ✨

3.4.2. PIM Join Attribute Hello Option 🎀

 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 = 26           |      OptionLength = 0        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

• Option type: 26. 🧚

4. IANA Considerations 📋

A new IANA registry has been created for "PIM Join Attribute Types". These are values of the "Attr_Type" field from section 3.4.1. Assignments are to be made according to the policy "IETF Review" as defined in [RFC5226] 💅

IANA has assigned the PIM Hello option value 26 to the "Join Attribute" option, with this document as the reference 🌸

[RFC4601] should have, but did not, create a registry for the "Encoding Type" field of the Encoded-Source Address format defined there 😤 IANA has set up one for it now, referencing both this document and [RFC4601]. Assignments should be made according to the policy "IETF Review" as defined in [RFC5226]. Two encoding types are defined 👑

• The encoding type 0 has been allocated, defined as "native encoding for the address family", and [RFC4601] is the reference. 🦋
• The encoding type 1 has been allocated, defined as "native encoding for the address family, but with zero or more PIM Join Attributes present", and this document is the reference. ✨

5. Security Considerations 🔒

Security of the Join Attribute is ONLY guaranteed by the security of the PIM packet 😱 So the security considerations for PIM Join packets in [RFC4601] apply here. Additional security considerations may apply to specific attributes; if so, they'll need to be documented in the specification of those attributes. 💀

Security considerations from [RFC5015] may apply as well 🙈

6. Acknowledgments 🫶

The authors would like to thank Stig Venaas, James Lingard, Bharat Joshi, Marshall Eubanks, Pekka Savola, Tom Pusateri, and Elwyn Davies for their input 💜

7. Normative References 📚

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
          Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
          "Protocol Independent Multicast - Sparse Mode (PIM-SM):
          Protocol Specification (Revised)", RFC 4601, August 2006.

8. Informative References 📖

[RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol
          Independent Multicast - Dense Mode (PIM-DM): Protocol
          Specification (Revised)", RFC 3973, January 2005.

[RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,
          "Bidirectional Protocol Independent Multicast (BIDIR-PIM)",
          RFC 5015, October 2007.

[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
          IANA Considerations Section in RFCs", BCP 26, RFC 5226, May
          2008.

Authors' Addresses 💌

Arjen Boers
Cisco Systems, Inc.
Avda. Diagnoal, 682
Barcelona 08034

EMail: aboers@cisco.com


IJsbrand Wijnands
Cisco Systems, Inc.
De kleetlaan 6a
Diegem  1831
Belgium

EMail: ice@cisco.com


Eric C. Rosen
Cisco Systems, Inc.
1414 Massachusetts Avenue
Boxborough, MA, 01719

EMail: erosen@cisco.com

---

That's the whole spec, bestie!! 🌈💖 Join Attributes ate and left no crumbs 💅✨