idnits 2.17.1 draft-venaas-pim-hierarchicaljoinattr-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC5384, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC5384, updated by this document, for RFC5378 checks: 2005-10-20) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 6, 2013) is 4089 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Venaas 3 Internet-Draft I. Kouvelas 4 Updates: 5384 (if approved) J. Arango 5 Intended status: Standards Track Cisco Systems 6 Expires: August 10, 2013 February 6, 2013 8 Hierarchical Join/Prune Attributes 9 draft-venaas-pim-hierarchicaljoinattr-00.txt 11 Abstract 13 This document defines a hierachical method of encoding Join 14 attributes, providing a more efficient encoding when the same 15 attribute values need to be specified for multiple sources in a PIM 16 Join/Prune message. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on August 10, 2013. 35 Copyright Notice 37 Copyright (c) 2013 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 54 3. Hierarchical Join/Prune Attribute Definition . . . . . . . . . 5 55 4. PIM Address Encoding Types . . . . . . . . . . . . . . . . . . 8 56 5. Hierarchical Join/Prune Attribute Hello Option . . . . . . . . 9 57 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 58 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 59 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 60 9. Normative References . . . . . . . . . . . . . . . . . . . . . 13 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 63 1. Introduction 65 PIM Join attributes as defined in [RFC5384] allow for specifying a 66 set of attributes for each of the joined or pruned sources in a PIM 67 Join/Prune message. Attributes must be separately specified for each 68 individual source in the message. However, in some cases the same 69 attributes and values need to be specified for some, or even all, the 70 sources in the message. The attributes and their values then need to 71 be repeated for each of the sources where they apply. 73 This document provides a hierarchical way of encoding attributes and 74 their values in a Join/Prune message, so that if the same attribute 75 and value is to apply for all the sources, it needs only be specified 76 once in the message. Similarly, if all the sources in a specific 77 group set share a specific attribute and value, it needs only be 78 specified once for the entire group set. 80 This document updates [RFC5384] which defines an encoding to be used 81 for Encoded-Source Addresses. This document extends this by 82 specifying the same encoding type also for Encoded-Unicast and 83 Encoded-Group formats. This document defines a new IANA registry for 84 PIM encoding types which is to be used for all the fields in PIM 85 messages where encoding types are used, replacing the old registry 86 that is specific to Encoded-Source Addresses. The encoding type used 87 for Join attributes is however still limited to be used in Join/Prune 88 messages. Note that Join attributes, as they are referred to in 89 [RFC5384], also apply to pruned sources in a Join/Prune message. 90 Thus the more correct name Join/Prune attributes will be used 91 throughout the rest of this document. 93 This document allows Join/Prune attributes to be specified in the 94 Upstream Neighbor Address field, and also in the Multicast Group 95 Address field, of a Join/Prune message. It defines how this is used 96 to specify the same Join/Prune attribute and value for multiple 97 sources. This document also introduces a new Hello Option to 98 indicate support for the hierarchical encoding specified. 100 2. Requirements Notation 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in [RFC2119]. 106 3. Hierarchical Join/Prune Attribute Definition 108 The format of a PIM Join/Prune message is defined in [RFC4601] as 109 follows: 111 0 1 2 3 112 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 113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 114 |PIM Ver| Type | Reserved | Checksum | 115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 116 | Upstream Neighbor Address (Encoded-Unicast format) | 117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 118 | Reserved | Num groups | Holdtime | 119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 120 | Multicast Group Address 1 (Encoded-Group format) | 121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 122 | Number of Joined Sources | Number of Pruned Sources | 123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 124 | Joined Source Address 1 (Encoded-Source format) | 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 126 | . | 127 | . | 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 | Joined Source Address n (Encoded-Source format) | 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 | Pruned Source Address 1 (Encoded-Source format) | 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 | . | 134 | . | 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 | Pruned Source Address n (Encoded-Source format) | 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 | . | 139 | . | 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 | Multicast Group Address m (Encoded-Group format) | 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 | Number of Joined Sources | Number of Pruned Sources | 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 | Joined Source Address 1 (Encoded-Source format) | 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | . | 148 | . | 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 | Joined Source Address n (Encoded-Source format) | 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 | Pruned Source Address 1 (Encoded-Source format) | 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | . | 155 | . | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | Pruned Source Address n (Encoded-Source format) | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 The message contains a single Upstream Neighbor Address, and one or 161 more group sets. Each group set contains a Group Address and two 162 source lists, the Joined Sources and the Pruned Sources. The 163 Upstream Neighbor Address, the group addresses and the source 164 addresses are all encoded in Encoded-Unicast format, Encoded-Group 165 format and Encoded-Source format, respectively. In this document we 166 make use of this to allow Join/Prune attributes in each of these 167 addresses, using the encoding in Section 4. 169 For a Join/Prune message we define a hierarchy of Join/Prune 170 attributes. At the highest level, that is the least specific, we 171 have attributes that apply to every source in the message. These are 172 encoded in the Upstream Neighbor Address. At the next more specific 173 level we have attributes that apply to every source in a group set. 174 They are encoded in a Group Address. And finally at the most 175 specific level, we have attributes that just apply to a single 176 source, encoded in the source address as defined in [RFC5384]. 178 The complete set of attributes that apply to a given source is 179 obtained by combining the message wide attributes, the attributes of 180 the group set that the source belongs to, and the source specific 181 attributes. However, if the same attribute is specified at multiple 182 levels, then the one at the most specific level overrides the other 183 instances of the attribute. 185 Note that Join/Prune attributes are still applied to sources as 186 specified in [RFC5384]. This document does not change the meaning of 187 any attributes, it is simply a more compact way of encoding an 188 attribute when the same attribute and value applies to multiple 189 sources. 191 4. PIM Address Encoding Types 193 Addresses in PIM messages are specified together with an address 194 family and an encoding type. This applies to Encoded-Unicast, 195 Encoded-Group and Encoded-Source addresses. The encoding types allow 196 the address to be encoded according to different schemes. While it 197 is possible to have the same encoding type value indicate different 198 encodings depending on whether it is a Unicast, Group or Source 199 address, it is simpler to have the same encoding type value indicate 200 the same encoding independent of where it is used. This means that 201 as currently defined, 0 means a native encoding, and 1 means there 202 are Join/Prune attributes, encoded according to [RFC5384]. Even if 203 the encoding type space is shared between the different address types 204 (Encoded-Unicast, Encoded-Group and Encoded-Source), one could have a 205 specific encoding apply to a specific address type if needed. 207 The current IANA PIM Encoded-Source Address Encoding Type Field 208 registry should be changed into a PIM Address Encoding Type registry. 210 5. Hierarchical Join/Prune Attribute Hello Option 212 A PIM router indicates that it supports the mechanism specified in 213 this document by including the Hierarchical Join/Prune Attribute 214 Hello Option in its PIM Hello message. Note that it also needs to 215 include the Join-Attribute Hello option as specified in [RFC5384]. 216 The format of the Hierarchical Join/Prune Attribute Hello Option is 217 defined to be: 219 0 1 2 3 220 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 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | OptionType = TBD | OptionLength = 0 | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 OptionType = TBD, OptionLength = 0. Note that there is no option 226 value included. 228 A PIM router MUST NOT send a Join/Prune message with Join/Prune 229 attributes encoded in the Upstream Neighbor Address or any of the 230 group addresses out any interface on which there is a PIM neighbor 231 that has not included this option in its Hellos. Even a router that 232 is not the upstream neighbor must be able to parse the message in 233 order to do Join suppression or Prune overriding. 235 6. Security Considerations 237 This document specifies a more compact encoding of Join/Prune 238 attributes. Use of the encoding has no impact on security. 240 7. IANA Considerations 242 The current PIM Encoded-Source Address Encoding Type Field registry 243 should be changed into a PIM Address Encoding Type registry. The 244 only required change is the name of the registry. The contents 245 remain the same. 247 A new PIM Hello Option type needs to be assigned. The string TBD 248 needs to be replaced with the permanently assigned value. 250 8. Acknowledgments 252 Acknowledgments to be added. 254 9. Normative References 256 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 257 Requirement Levels", BCP 14, RFC 2119, March 1997. 259 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 260 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 261 Protocol Specification (Revised)", RFC 4601, August 2006. 263 [RFC5384] Boers, A., Wijnands, I., and E. Rosen, "The Protocol 264 Independent Multicast (PIM) Join Attribute Format", 265 RFC 5384, November 2008. 267 Authors' Addresses 269 Stig Venaas 270 Cisco Systems 271 Tasman Drive 272 San Jose, CA 95134 273 USA 275 Email: stig@cisco.com 277 Isidor Kouvelas 278 Cisco Systems 279 Tasman Drive 280 San Jose, CA 95134 281 USA 283 Email: kouvelas@cisco.com 285 Jesus Arango 286 Cisco Systems 287 Tasman Drive 288 San Jose, CA 95134 289 USA 291 Email: jearango@cisco.com