idnits 2.17.1 draft-ietf-magma-igmpv3-and-routing-05.txt: 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: ---------------------------------------------------------------------------- == There are 2 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard 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.) ** There are 4 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (April 2004) is 7315 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) == Missing Reference: 'RFC 2026' is mentioned on line 13, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'MLDv2' -- Possible downref: Non-RFC (?) normative reference: ref. 'DVMRP' ** Downref: Normative reference to an Historic RFC: RFC 1584 (ref. 'MOSPF') -- Possible downref: Non-RFC (?) normative reference: ref. 'PIMDM' -- Possible downref: Non-RFC (?) normative reference: ref. 'PIMSM' -- Possible downref: Non-RFC (?) normative reference: ref. 'SSM' Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MAGMA Working Group B. Haberman 2 Internet Draft Caspian Networks 3 draft-ietf-magma-igmpv3-and-routing-05.txt J. Martin 4 October 2003 Netzwert AG 5 Expires April 2004 7 IGMPv3/MLDv2 and Multicast Routing Protocol Interaction 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026 [RFC 2026]. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. Internet-Drafts are draft documents valid for a maximum of 18 six months and may be updated, replaced, or obsoleted by other 19 documents at any time. It is inappropriate to use Internet-Drafts as 20 reference material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt. 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Abstract 30 The definitions of IGMPv3 and MLDv2 require new behavior within the 31 multicast routing protocols. The additional source information 32 contained in IGMPv3 and MLDv2 messages necessitates multicast 33 routing protocols to manage and utilize the information. This 34 document describes how multicast routing protocols will interact 35 with these source-filtering group management protocols. 37 1. Introduction 39 The definitions of IGMPv3[IGMP3] and MLDv2[MLDv2] require new 40 behavior within the multicast routing protocols. The additional 41 source information contained in IGMPv3 and MLDv2 messages 42 necessitates multicast routing protocols to manage and utilize the 43 information. This document will describe how multicast routing 44 protocols will interpret information learned from these source- 45 filtering group management protocols. 47 2. Multicast Forwarding State 49 Haberman, Martin 1 50 Existing multicast routing protocols utilize the group management 51 database in determining if local members exist for a particular 52 multicast group. With previous group management protocols, this 53 database had one type of record indicating the group for which there 54 was interest and the associated local interfaces. 56 In the case of IGMPv3 and MLDv2, these routing protocols may now 57 build multicast forwarding state based on the source filter 58 information available for each multicast group that has local 59 membership. This requires the group management database to have four 60 record types. Only one record may exist for a given interface and a 61 given multicast group. 63 1. EXCLUDE <> 64 The EXCLUDE <> record indicates interest in all sources 65 destined to this group address for a set of local interfaces. 66 It is equivalent to the single record type existing in previous 67 versions of the group management protocols. 68 2. INCLUDE <> 69 The INCLUDE <> record indicates that there is no interest in 70 any sources destined to this group address for a set of local 71 interfaces. 72 3. EXCLUDE 73 The EXCLUDE record indicates that there is interest in 74 only the specifically listed sources for a set of local 75 interfaces. 76 4. INCLUDE 77 The INCLUDE record indicates that there is interest in 78 only the specifically listed sources for a set of local 79 interfaces. 81 The records in the group management database should be utilized when 82 generating forwarding state for a multicast group. If the source 83 address in the multicast packet exists in the database for the 84 specified multicast group and is in an INCLUDE list or is not listed 85 in an EXCLUDE list, the multicast routing protocol should add the 86 interface to the list of downstream interfaces, otherwise it should 87 not be added based on local group membership. 89 3. DVMRP Interaction 91 The DVMRP protocol[DVMRP] interaction with a source-filtering group 92 management protocol is important in two areas: multicast 93 distribution tree pruning and multicast distribution tree grafting. 94 The following sections will describe the behavior needed in DVMRP to 95 interoperate with IGMPv3 and MLDv2. 97 3.1 DVMRP Prunes 99 Haberman, Martin 2 100 DVMRP prune messages are initiated when a DVMRP router determines 101 that there are no entities interested in the data flowing on the 102 (S,G) forwarding state. If the multicast router is running IGMPv3 103 or MLDv2, this is determined by the source S being in EXCLUDE state 104 in the source filter for the destination G or all interest in G 105 being terminated for an existing (S,G) forwarding entry. 107 3.2 DVMRP Grafts 109 DVMRP graft messages are sent in order to override an existing DVMRP 110 prune. In the case of IGMPv3 or MLDv2, this occurs when prune state 111 exists for (S,G) and a state change occurs in which the source 112 filter state for S changes to INCLUDE for the specified G. 114 4. MOSPF Interaction 116 In MOSPF[MOSPF], the consideration of source filter information in 117 the group management database is limited to the building of 118 forwarding state (discussed above). This is due to the flooding of 119 group-membership-LSAs within MOSPF. 121 5. PIM-DM Interaction 123 Like DVMRP, PIM-DM[PIMDM] must utilize the source filter information 124 when generating Prune and Graft messages. The following sections 125 describe the creation of these message types. 127 5.1 PIM-DM Prunes 129 PIM-DM prune messages are initiated when a PIM-DM router determines 130 that there are no entities interested in the data flowing on the 131 (S,G) forwarding state. If the multicast router is running IGMPv3 132 or MLDv2, this is determined by the source S being in EXCLUDE state 133 in the source filter for the destination G or all interest in G 134 being terminated for an existing (S,G) forwarding entry. 136 5.2 PIM-DM Grafts 138 PIM-DM graft messages are sent in order to override an existing PIM- 139 DM prune. In the case of IGMPv3 or MLDv2, this occurs when prune 140 state exists for (S,G) and a state change occurs in which the source 141 filter state for S changes to INCLUDE for the specified G. 143 6. PIM-SM Interaction 145 A PIM-SM interaction takes place when a PM-SM[PIMSM] router receives 146 an IGMP or MLD message regarding a group address that is in the Any 148 Haberman, Martin 3 149 Source Multicast (ASM) range. This range is defined as the entire 150 multicast address space excluding the global SSM range [SSM] and any 151 locally defined Source Specific space. 153 6.1 PIM-SM Joins (ASM Behavior) 155 PIM-SM join messages are initiated when a PIM-SM router determines 156 that there are entities interested in a specific group or a specific 157 source sending to the group. If this is due to a IGMPv3 or MLDv2 158 report with a zero-length EXCLUDE list, then the join is sent as a 159 (*,G) join towards the RP. 161 If the join is triggered by an IGMPv3 or MLDv2 state change that 162 affects source information, the PIM-SM join is sent as a (S,G) join 163 towards the specific source. This behavior optimizes the join 164 process, as well as facilitates the adoption of the SSM model. The 165 generation of this (S,G) join can cause failures in architectures 166 where leaf routers do not have global reachability, and thus, can be 167 overridden by local policy. If this is the case, then all triggered 168 joins are sent towards the RP as (*,G) joins. The router sending the 169 (*,G) join is responsible for filtering the data as per the IGMPv3 170 database before forwarding. 172 6.2 PIM-SM Prunes (ASM Behavior) 174 PIM-SM prune messages are initiated when a PIM-SM router determines 175 that there are no entities interested in a specific group, or a 176 specific source sending to the group. If this is triggered by either 177 receiving a report with an EXCLUDE or if a specific Source/Group 178 times out, then an (S,G) prune is sent towards the upstream router. 179 If all of the IGMPv3 or MLDv2 derived requests for a group time out, 180 then (S,G) and (*,G) prunes are sent upstream as needed to stop all 181 flow of traffic for that group. 183 7. PIM-SSM Interaction 185 A PIM-SSM interaction takes place when a PIM-SM router receives an 186 IGMPv3 or MLDv2 message regarding a group address that is in the 187 Source Specific Multicast range. This behavior is not defined in 188 this document, but rather in [PIMSM]. 190 8. Security Considerations 192 This document does not introduce any additional security issues 193 above and beyond those already discussed in [PIMSM], [IGMP3], and 194 [MLDv2]. 196 Haberman, Martin 4 197 9. Acknowledgements 199 The authors would like to thank Murali Brahmadesam, Leonard 200 Giuliano, and Hal Sandick for their feedback and suggestions. 202 10. Authors' Addresses 204 Brian Haberman 205 Caspian Networks 206 753 Bridgewater Drive 207 Sykesville, MD 21784 209 brian@innovationslab.net 210 +1-410-552-1421 212 Jim Martin 213 Netzwert AG 214 An den Treptowers 1 215 D-12435 Berlin 217 jim@Netzwert.AG 218 +49.30/5 900 800-180 220 11. References 221 11.1 Normative References 222 [IGMP3] B. Cain, et al, "Internet Group Management Protocol, Version 223 3", RFC 3376, October 2002. 225 [MLDv2] R. Vida, et al., �Multicast Listener Discovery Version 2 226 (MLDv2) for IPv6�, work in progress. 228 [DVMRP] T. Pusateri, "Distance Vector Multicast Routing Protocol", 229 work in progress. 231 [MOSPF] J. Moy, "Multicast Extensions to OSPF", RFC 1584, March 232 1994. 234 [PIMDM] A. Adams, et al, "Protocol Independent Multicast - Dense 235 Mode: Protocol Specification (Revised)", work in progress. 237 [PIMSM] B.Fenner, et al, "Protocol Independent Multicast -Sparse 238 Mode (PIM-SM): Protocol Specification (Revised)", work in 239 progress. 241 [SSM] H. Holbrook, et al, "Source-Specific Multicast for IP", work 242 in progress. 244 Haberman, Martin 5 245 Full Copyright Statement 247 Copyright (C) The Internet Society (2003). All Rights Reserved. 249 This document and translations of it may be copied and furnished to 250 others, and derivative works that comment on or otherwise explain it 251 or assist in its implementation may be prepared, copied, published 252 and distributed, in whole or in part, without restriction of any 253 kind, provided that the above copyright notice and this paragraph 254 are included on all such copies and derivative works. However, this 255 document itself may not be modified in any way, such as by removing 256 the copyright notice or references to the Internet Society or other 257 Internet organizations, except as needed for the purpose of 258 developing Internet standards in which case the procedures for 259 copyrights defined in the Internet Standards process must be 260 followed, or as required to translate it into languages other than 261 English. 263 The limited permissions granted above are perpetual and will not be 264 revoked by the Internet Society or its successors or assigns. 266 This document and the information contained herein is provided on an 267 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 268 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 269 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 270 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 271 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 273 This document expires in April, 2004. 275 Haberman, Martin 6