diff options
Diffstat (limited to 'doc/rfc/rfc5384.txt')
| -rw-r--r-- | doc/rfc/rfc5384.txt | 563 |
1 files changed, 563 insertions, 0 deletions
diff --git a/doc/rfc/rfc5384.txt b/doc/rfc/rfc5384.txt new file mode 100644 index 0000000..8ed8c34 --- /dev/null +++ b/doc/rfc/rfc5384.txt @@ -0,0 +1,563 @@ + + + + + + +Network Working Group A. Boers +Request for Comments: 5384 I. Wijnands +Category: Standards Track E. Rosen + Cisco Systems, Inc. + November 2008 + + + The Protocol Independent Multicast (PIM) + Join Attribute Format + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (c) 2008 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. + +Abstract + + A "Protocol Independent Multicast - Sparse Mode" Join message sent by + a given node identifies one or more multicast distribution trees that + that node wishes to join. Each tree is identified by the combination + of a multicast group address and a source address (where the source + address is possibly a "wild card"). Under certain conditions it can + be useful, when joining a tree, to specify additional information + related to the construction of the tree. However, there has been no + way to do so until now. This document describes a modification of + the Join message that allows a node to associate attributes with a + particular tree. The attributes are encoded in Type-Length-Value + format. + + + + + + + + +Boers, et al. Standards Track [Page 1] + +RFC 5384 PIM Join Attribute November 2008 + + +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 + + In the protocol known as "Protocol Independent Multicast - Sparse + Mode" [RFC4601] (henceforth referred to as "PIM"), a Join message + sent by a given node may identify one or more multicast distribution + trees that that node wishes to join. Each tree is identified by the + combination of a multicast group address and a source address (where + the source address is possibly a "wild card"). Under certain + conditions it can be useful, when joining a tree, to specify + additional information related to the construction of the tree. + However, there has been no way to do so until now. This document + describes a modification of the Join message that allows a node to + associate an attribute, encoded in Type-Length-Value (TLV) format, + with a particular tree that it wishes to join. These attributes are + known as "PIM Join Attributes". + + In the PIM Join message, the Source Address is identified by being + encoded as an "Encoded-Source Address" ([RFC4601], section 4.9.1). + Each Encoded-Source Address occurs in the context of a particular + group address, represented as an "Encoded-Group Address". Together, + the Encoded-Source Address and the Encoded-Group Address identify a + multicast distribution tree. The Encoded-Source Address contains an + "encoding type" field. The only value defined in [RFC4601] is 0. + This specification is the first to assign another encoding type + value. + + + + + +Boers, et al. Standards Track [Page 2] + +RFC 5384 PIM Join Attribute November 2008 + + + In order to associate TLVs with a particular tree, this specification + defines a new encoding type for the Encoded-Source Address: type 1. + When type 1 is used, the Encoded-Source Address may contain a + sequence of "Join Attributes", each of which is encoded as a TLV. + Then the type 1 Encoded-Source Address, in the context of the + associated Encoded-Group Address, identifies a multicast distribution + tree and specifies (via the Join Attribute TLVs) the attributes that + apply to the tree. Apart from the fact that the type 1 Encoded- + Source Address may contain Join Attributes, it is otherwise identical + to the type 0 Encoded-Source Address. + + This document does not contain the specification for any particular + Join Attribute. It specifies how Join Attributes are to be encoded + into the Join messages and it specifies generic procedures that are + common to all Join Attributes. The content and purpose of any + particular Join Attribute is outside the scope of this document. + + The use of Join Attributes in "Protocol Independent Multicast - Dense + Mode" [RFC3973] is not considered. + +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 are encoded as TLVs into the Encoded-Source Address + field of a PIM Join message, as specified in section 3.4.1 below. + Each attribute applies to the same multicast distribution tree that + is identified by the combination of the Encoded-Source Address and + the associated Encoded-Group Address. The multicast distribution + tree may be either a source-specific tree or a shared tree. + + The encoding of the "source address" field within the Encoded-Source + Address is exactly the same for a type 1 Encoded-Source Address as + for a type 0 Encoded-Source Address, specified in [RFC4601]. + + A type 1 Encoded-Source Address MUST contain at least one Join + Attribute. The way to specify that there are no Join Attributes for + a particular tree is to use the type 0 Encoded-Source Address. + + + + + + + +Boers, et al. Standards Track [Page 3] + +RFC 5384 PIM Join Attribute November 2008 + + + Multiple Join Attributes of the same type or of different types may + occur within a single Encoded-Source Address. This specification + does not require all attributes of a given type to occur + contiguously. There is no header field that specifies the number of + attributes; rather the last attribute is specially marked as such. + + Any PIM router that does not understand the type 1 Encoded-Source + Address will not be able to process a PIM Join message that contains + it. Further, if the use of any particular Join Attribute affects the + construction of the multicast distribution tree, the tree may not be + formed correctly unless the attribute is understood by all PIM + routers that receive it. As a consequence, attributes are only + useful within a single administrative domain (or perhaps a small set + of contiguous, cooperating administrative domains) where it can be + determined a priori that all deployed PIM routers understand the type + 1 Encoded-Source Address, as well as whatever specific attributes are + in use. + +3.2. The Join Attribute Option in the PIM Hello + + To ensure that a type 1 Encoded-Source Address is not sent to a PIM + neighbor that does not understand this encoding, a new PIM Hello + option, the "Join Attribute" option, is defined. This option MUST be + included in the PIM Hellos of any PIM router that is willing to + receive type 1 Encoded-Source Address. A PIM router MUST NOT send a + type 1 Encoded-Source Address 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 parse the + packet in order to do Join suppression or overriding.) + + Note that a PIM router that sends the "Join Attribute" Hello option + does not necessarily understand every possible attribute type. As + there is no immediate way to act on a neighbor's inability to process + certain attribute types, it is not desired to have a Hello option for + each 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 in which they appear. + + The specification for a given attribute type MUST specify the + procedure to apply if there are multiple instances of that attribute + type. + + + + + +Boers, et al. Standards Track [Page 4] + +RFC 5384 PIM Join Attribute November 2008 + + + Processing an attribute may affect the following: + + - the construction of the associated multicast distribution tree, + + - the processing of other attributes of the same type that also occur + 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 occur in the type 1 Encoded- + Source Address. + + If the processing of a received attribute has any effect on the + construction of the multicast distribution tree or on the set of + attributes that are forwarded up the tree, then state MUST be + maintained associating the received attribute with the adjacency or + adjacencies from which it was received. + +3.3.2. Transitive and Non-Transitive Attributes + + If a PIM router understands a particular attribute type, the + attribute is processed as specified above. + + If a PIM router does not understand the type of a particular + attribute, the PIM router either forwards that attribute or discards + it, depending upon the setting of the attribute's F-bit. If the + F-bit is set, then the router MUST forward the attribute; if the + F-bit is clear, then the router MUST discard it. + + If one or more non-transitive attributes are discarded, the rest of + the Join Attributes (if any) are still forwarded. 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 + + It is possible that a router receives conflicting attribute + information from different downstream routers. Conflicts only occur + with attributes of the same type. + + ( Edge A1 ) ( Edge B1 )---- [R1] + / \ / + / \ / + [S] ( Core ) + \ / \ + \ / \ + ( Edge A2 ) ( Edge B2 )---- [R2] + + Figure 1 + + + +Boers, et al. Standards Track [Page 5] + +RFC 5384 PIM Join Attribute November 2008 + + + As an example, consider Figure 1 and suppose a Join Attribute is used + to indicate a choice of exit router. There are 2 receivers for the + same group connected to Edge B1 and B2. Suppose that edge router B1 + prefers A1 and B2 prefers A2 as exit points to reach the source S. + If both Edge B1 and B2 send a Join including an attribute to prefer + their exit router in the network and they cross the same core router, + the core router will get conflicting attribute information for the + source. If this happens, we use the attribute from the PIM adjacency + with the numerically smallest IP address. In the case of IPv6, the + link local address will be used. When two neighbors have the same IP + address, either for IPv4 or IPv6, the interface index MUST be used as + a tie breaker. The attributes from other sending routers MAY be + remembered; that way, if the adjacency that supplied the selected + attribute gets pruned or expires, we are able to immediately use the + attribute that was sent by the adjacency that is next in the order of + preference. This enables us to converge quickly without waiting for + the next periodic update. + + When a particular attribute type is specified, the specification MAY + include a conflict resolution procedure specific to that type. If + so, that conflict resolution procedure MUST be used instead of the + procedure described in this section. + + It is possible that a router will receive, from two different + adjacencies, transitive attributes of a given type. If the router + does not understand attributes of that type and if the two + adjacencies have not sent the exact same set of attributes of that + type, then the conflict resolution procedure described in this + section MUST be applied to those attributes. Two adjacencies are + said to have sent the exact same set of attributes of a given type if + they have sent the same number of instances of that attribute and if + corresponding instances are byte-for-byte identical. + +3.3.4. Attribute Change + + A PIM router may decide to change the set of attributes it has + associated with a given multicast distribution tree. This can happen + if one of its downstream neighbors on the tree has changed the set of + attributes. It can also happen as a result of processing the + attributes. It can also happen for reasons outside the scope of this + specification (such as a change in configuration). + + If a PIM router needs to change the set of attributes for a given + tree but does not change its upstream neighbor for that tree, it MUST + send a new Join for that tree, specifying the new set of attributes. + If the new set of attributes is the null set, the type 0 Encoded- + Source format MUST be used. + + + + +Boers, et al. Standards Track [Page 6] + +RFC 5384 PIM Join Attribute November 2008 + + + If a PIM router needs to change the set of attributes for a given + tree and as a result changes its upstream neighbor for that tree, it + sends a Prune to the old upstream neighbor. The Prune does not need + to carry any attributes. + + When a PIM router receives a Join for a given tree and the Join does + not contain exactly the same set of attributes as the prior Join, the + set of attributes in the new Join becomes the entire new set of + attributes. No attribute information from the prior Join is + retained. There is no way to advertise incremental changes to the + set of attributes; any attributes that are no longer present are + considered to have been withdrawn. If, as the result of receiving a + Join, a PIM router determines that the set of attributes has changed, + it will need to send a new Join upstream that contains the new set of + attributes. (Of course, the procedures for resolving attribute + conflicts may need to be applied first.) + + When a PIM router R1 receives a Prune for a given tree from a given + downstream neighbor R2, where R2 had previously sent attributes + applying to that tree, those attributes are considered to have been + withdrawn. Depending on the attributes that R1 has received from its + other downstream neighbors (if any) on the tree, R1 may determine + that the set of attributes applying to the tree has changed, in which + case 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 is no space in the default PIM source encoding to include an + attribute field. Therefore 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+..... + . . . + . . . + + + +Boers, et al. Standards Track [Page 7] + +RFC 5384 PIM Join Attribute November 2008 + + + - Encoding Type: 1 + + - F-bit, Transitive Attribute. If this bit is set, the attribute is + a transitive attribute; otherwise, it is a non-transitive + attribute. See section 3.3.2. + + - E-bit, End of Attributes. If this bit is set, then this is the + last Join Attribute appearing in this Encoded-Source Address field. + + - "Attr_Type", a 6-bit field identifying the type of the Attribute. + + - Length field, a 1-octet field specifying the length in octets, + encoded as an 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 depicted in 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 + therein. IANA has set up a registry for this, 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. + + + + + + +Boers, et al. Standards Track [Page 8] + +RFC 5384 PIM Join Attribute November 2008 + + + - 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 + as described in [RFC4601] apply here. Additional security + considerations may apply to specific attributes; if so, these will + 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. + + + + + + + + + +Boers, et al. Standards Track [Page 9] + +RFC 5384 PIM Join Attribute November 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 + + + + + + + + + + + + + + + + + + + + + + + + + + +Boers, et al. Standards Track [Page 10] + |