idnits 2.17.00 (12 Aug 2021) /tmp/idnits12420/draft-keyur-pim-host-extensions-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 5) being 97 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 6 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 17 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** There are 2 instances of lines with control characters in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 277: '...esses and Pruned Source addresses MUST...' RFC 2119 keyword, line 280: '...s in the message SHOULD be the same as...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '8' on line 140 -- Looks like a reference, but probably isn't: '5' on line 230 -- Possible downref: Non-RFC (?) normative reference: ref. 'PIM-SM' ** Downref: Normative reference to an Informational RFC: RFC 1701 (ref. 'Han94a') ** Downref: Normative reference to an Informational RFC: RFC 1702 (ref. 'Han94b') Summary: 10 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Keyur Patel 2 Internet Draft AYR Networks 3 Expiration Date: January 2003 Radia Perlman 4 Sun Microsystems 6 Host Extensions to Protocol Independent Multicast 8 draft-keyur-pim-host-extensions-00.txt 10 1. Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as ``work in progress.'' 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 2. Abstract 33 This document defines host extensions to Protocol Independent 34 Multicast - PIM protocol. These host extensions allows endnodes 35 to join/leave any multicast (S/*,G) groups. This helps in easing 36 SSM-style multicast deployment that does not have to depend on 37 IGMP (v1/v2/v3), in either endnodes or the routers. 39 3. Introduction 41 An impediment to getting SSM Multicast deployed is that, as currently 42 specified, it depends on IGMPv3. Since IGMPv3 is in the IP stack, it 43 requires endnodes to upgrade to an OS that supports IGMPv3 and it 44 requires IGMPv3 support on the first hop multicast capable routers as 45 well. This document proposes host extensions to PIM protocol which 46 eliminate the requirement of running IGMPv3 both on endnodes as well 47 as first hop multicast capable routers. This draft is solely for the 48 purpose of joining SSM-style groups, i.e., groups in which the IP 49 address of the root is explicitly known by the joining host. This 50 draft allows hosts to join SSM-style groups even if 52 * the host's OS stack does not support IGMPv3 53 * the local routers do not support IGMPv3, or even multicast, and/or 54 * some routers along the path to the root do not support multicast. 56 This is achieved by defining a new user level process that runs host 57 extensions for PIM. All that is really required to join an SSM-style 58 group with this mechanism is for the joining host and the root (the 59 "Source") to support this. As more routers are upgraded to supporting 60 this, bandwidth use is minimized by utilizing multicast rather than 61 tunnels. 63 Although in theory this style of host join could be used instead of 64 IGMP to join a non-SSM group, for non-SSM groups this design offers 65 no advantage over IGMP, since only IGMPv2, which is already widely 66 deployed, is required for joining non-SSM groups. 68 A router that does not support the messages in this draft 69 will simply forward such messages towards the destination specified 70 in the messages. The first multicast capable router that supports 71 these PIM host extensions will notice these messages and will form a 72 tunnel with the end node that generated the message. 74 4 Host extensions for PIM 76 We propose a new PIM Host-Join/Prune message that is similar to the 77 PIM Join/Prune message, except that the destination address in the 78 IP header is the "Source" (root of the tree) address. PIM routers 79 with host extension support will process these messages without 80 requiring an exchange of the PIM hello messages or establishing the 81 PIM neighbor adjacencies. PIM routers should treat the receipt of 82 Host-Join/Prunes messages as intended for them, even though the 83 destination address in the IP header is the unicast address 84 of the tree root. To allow a router to recognize a PIM Host-Joins 85 addressed to the unicast root address, and place it on the slow 86 path, rather than simply forwarding it towards the specified 87 destination, the packet will have the router alert option, and the IP 88 protocol type="PIM" with version 2. 90 PIM routers with host extension support receiving such PIM 91 Host-Join/Prune messages will process them in similar way as PIM 92 Join/Prune messages. PIM routers however will create tunnel interfaces 93 (refer section 6) in their (S, G) oif lists when receiving 94 Host-Join/Prune messages from receivers that are not directly connected. 95 For all the directly connected receivers, PIM routers will create 96 interfaces in their (S, G) oif lists in the same way as if an IGMP (S,G) 97 join or a PIM Join/Prune message were received. An implementation must 98 have a configured upper bound on number of tunnel interfaces that it can 99 put in oif lists of any multicast route. PIM routers receiving such 100 PIM Host-Join/Prune messages will process them exactly as PIM Join/Prune 101 messages and will have similar state-machine generated by these messages 102 (as described in [PIM-SM]). It is suggested that an implementation must 103 have a seperate mechanism for processing all the PIM Host-Join/Prune 104 messages within a PIM process in order to prevent any kind of interference 105 with PIM router messages. All the non-multicast PIM capable routers 106 will simply forward such packets towards the unicast source address. 107 Current routers which receive an ip unicast packet with ip options 108 process these packets and forward them towards the unicast destination 109 address specified in the ip packet if the destination is not one of the 110 ip addresses of the routers. Otherwise, these routers forward these 111 packets up the local stack for local delivery. Therefore, current 112 routers will forward the packets destined for the unicast address of the 113 root, to the root, which is the desired behavior. 115 All end-hosts willing to subscribe to a particular (S/*, G) group 116 will be periodically sending PIM Host-Join messages. All the PIM 117 Host-Join/Prune messages will be sent with unicast source address 118 as the destination address. All the PIM Host-Join/Prune messages 119 will be sent with IP Router Alert option. 121 5 PIM Host-Join/Prune message format 123 PIM Host-Joins are sent to assist building source trees (SPT). PIM 124 Host-Prunes are sent to prune source trees when members leave groups. 126 Encoded-Unicast address 127 An Encoded-Unicast address takes the following format: 129 0 1 2 3 130 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 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 | Addr Family | Encoding Type | Unicast Address 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... 135 Addr Family 136 The PIM address family of the 'Unicast Address' field of this 137 address. 139 Values of 0-127 are as assigned by the IANA for Internet Address 140 Families in [8]. Values 128-250 are reserved to be assigned by the 141 IANA for PIM-specific Address Families. Values 251 though 255 are 142 designated for private use. As there is no assignment authority 143 for this space, collisions should be expected. 145 Encoding Type 146 The type of encoding used within a specific Address Family. The 147 value `0' is reserved for this field, and represents the native 148 encoding of the Address Family. 150 Unicast Address 151 The unicast address as represented by the given Address Family and 152 Encoding Type. 154 0 1 2 3 155 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 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 |PIM Ver| Type | Reserved | Checksum | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 | Reserved | Num groups | Holdtime | 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | Multicast Group Address 1 (Encoded-Group format) | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | Number of Joined Sources | Number of Pruned Sources | 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | Joined Source Address 1 (Encoded-Source format) | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 | . | 168 | . | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | Joined Source Address n (Encoded-Source format) | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | Pruned Source Address 1 (Encoded-Source format) | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 | . | 175 | . | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 | Pruned Source Address n (Encoded-Source format) | 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 | . | 180 | . | 181 | . | 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 | Multicast Group Address m (Encoded-Group format) | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | Number of Joined Sources | Number of Pruned Sources | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | Joined Source Address 1 (Encoded-Source format) | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | . | 190 | . | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 | Joined Source Address n (Encoded-Source format) | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | Pruned Source Address 1 (Encoded-Source format) | 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 | . | 197 | . | 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 | Pruned Source Address n (Encoded-Source format) | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 PIM Ver 203 PIM Version number is 2. 205 Type 206 Types for specific PIM messages. PIM Types are: 208 Message Type Destination 209 ------------------------------------------------------------------------- 210 0 = Hello Multicast to ALL-PIM-ROUTERS 211 1 = Register Unicast to RP 212 2 = RegisterStop Unicast to source of Register packet 213 3 = Join/Prune Multicast to ALL-PIM-ROUTERS 214 4 = Bootstrap Multicast to ALL-PIM-ROUTERS 215 5 = Assert Multicast to ALL-PIM-ROUTERS 216 6 = Graft (used in PIM-DM only) Multicast to ALL-PIM-ROUTERS 217 7 = Graft-Ack (used in PIM-DM only) Unicast to source of Graft packet 218 8 = Candidate-RP-Advertisement Unicast to Domain's BSR 219 9 = Host-Join/Prune Unicast to Source 221 Reserved 222 Set to zero on transmission. Ignored upon receipt. 224 Checksum 225 The checksum is a standard IP checksum, i.e. the 16-bit one's 226 complement of the one's complement sum of the entire PIM message. 227 For computing the checksum, the checksum field is zeroed. 229 For IPv6, the checksum also includes the IPv6 "pseudo-header", as 230 specified in RFC 2460, section 8.1 [5]. This "pseudo-header" is 231 prepended to the PIM header for the purposes of calculating the 232 checksum. The "Upper-Layer Packet Length" in the pseudo-header is 233 set to the length of the PIM message. The Next Header value used 234 in the pseudo-header is 103. If the packet's length is not an 235 integral number of 16-bit words, the packet is padded with a byte 236 of zero before performing the checksum. 238 Reserved 239 Transmitted as zero, ignored on receipt. 241 Holdtime 242 The amount of time a receiver must keep the Join/Prune state alive, 243 in seconds. If the Holdtime is set to `0xffff', the receiver of 244 this message should hold the state until canceled by the 245 appropriate canceling Join/Prune message, or timed out according to 246 local policy. This may be used with dial-on-demand links, to avoid 247 keeping the link up with periodic Join/Prune messages. 249 Note that the Holdtime must be larger than the 250 J/P_Override_Interval(I) (refer to [PIM-SM]). 252 Number of Groups 253 The number of multicast group sets contained in the message. 255 Multicast group address 256 For format description refer to Encoded-Unicast address. 258 Number of Joined Sources 259 Number of join source addresses listed for a given group. 261 Join Source Address 1 .. n 262 This list contains the sources that the sending router will forward 263 multicast datagrams for if received on the interface this message 264 is sent on. 266 See Encoded-Source-Address format. 268 Number of Pruned Sources 269 Number of prune source addresses listed for a group. 271 Prune Source Address 1 .. n 272 This list contains the sources that the sending router does not 273 want to forward multicast datagrams for when received on the 274 interface this message is sent on. 276 Within one PIM local-Join/Prune message, all the Multicast Group 277 Addresses, Joined Source addresses and Pruned Source addresses MUST 278 be of the same address family. It is NOT PERMITTED to mix IPv4 and 279 IPv6 addresses within the same message. In addition, the address 280 family of the fields in the message SHOULD be the same as the IP 281 source and destination addresses of the packet. This permits 282 maximum implementation flexibility for dual-stack IPv4/IPv6 routers. 284 6. Tunnel Interfaces 285 Because not all intermediate routers support native ip multicast, PIM 286 host extensions requires all the oifs on which it receives 287 Host-Join/Prunes messages from receivers which are not directly 288 connected to be created as tunnel interfaces. In practice, tunnels 289 typically use either IP-IP [Perk96] or Generic Routing Encapsulation 290 (GRE) [Han94a,Han94b], although, other encapsulation methods are 291 acceptable. 293 7. Security Considerations 295 This extension to PIM does not change the underlying security issues. 297 8. Acknowledgements 299 We express our thanks to Alex Zinin, Dino Farinacci, Tom Pusateri, 300 and Nidhi Bhaskar for their review and comments. 302 9. References 304 [PIM-SM] Bill Fenner, Mark Handley, Hugh Holbrook, Isidor Kouvelas, 305 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 306 Protocol Specification (Revised)". 308 [Han94a] Hanks, S., Li, T, Farinacci, D., and P. Traina, "Generic 309 Routing Encapsulation", RFC 1701, NetSmiths, Ltd., and 310 cisco Systems, October 1994. 312 [Han94b] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic 313 Routing Encapsulation over IPv4 networks", RFC 1702, 314 NetSmiths, Ltd., cisco Systems, October 1994. 316 [Perk96] Perkins, C., "IP Encapsulation within IP", RFC 2003, 317 October 1996. 319 10. Author Information 321 Keyur Patel 322 AYR Networks. Inc. 323 3977 East Bayshore Road, suite 200 324 Palo Alto, CA 94303 325 email: keyur@ayrnetworks.com 327 Radia Perlman 328 Sun Microsystems. Inc. 329 2 Elizabeth Drive 330 Chelmsford, MA 01824 331 email: Radia.Perlman@sun.com