idnits 2.17.1 draft-ietf-idmr-dvmrp-v3-as-01.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: ---------------------------------------------------------------------------- ** 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 7 longer pages, the longest (page 2) being 71 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 7 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 192 has weird spacing: '...for the purpo...' -- 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 (May 12, 2004) is 7282 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 section? 'Pusa03' on line 163 looks like a reference -- Missing reference section? 'Perl92' on line 160 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 T. Pusateri 2 INTERNET DRAFT Juniper Networks 3 draft-ietf-idmr-dvmrp-v3-as-01 May 12, 2004 4 Expires: November 12, 2004 6 Distance Vector Multicast Routing Protocol Applicability Statement 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet- Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 This document provides a framework for the use of Distance Vector 32 Multicast Routing Protocol (DVMRP) Version 3 within a multicast 33 routing domain. It is an interior gateway protocol designed to be 34 used within an autonomous system. 36 1. Intended use 38 DVMRP [Pusa03] can be characterized as a broadcast and prune 39 multicast routing protocol. This means that IP multicast datagrams 40 are forwarded to all possible receivers and then unwanted data 41 traffic is pruned back to the minimum tree necessary to reach all of 42 the current receivers. 44 This provides a data driven mechanism for all last hop routers to 45 learn about all active multicast sources. If the last hop routers 46 have local group members for the multicast group associated with the 47 source, they simply do nothing and the multicast data will continue 48 to arrive. 50 If the last hop routers do not have corresponding group members for 51 the active source, then they send control messages back up the 52 multicast delivery tree toward the source to prune their branch from 53 the tree. 55 The prunes sent upstream toward the source time out and are 56 periodically refreshed to reduce the amount of state that is stored. 57 The periodic broadcast and prune nature of the protocol makes it well 58 suited for use within a multicast domain or autonomous system where 59 bandwidth is plentiful. It is NOT intended for use as an EGP across 60 multicast domains or for interconnecting multicast domains. 62 DVMRP's advantages compared with other multicast routing protocols 63 include: 65 a. Pure source specific multicast distribution trees provide a simple 66 model to deploy and troubleshoot. 68 b. Join latency is minimized since new sources are automatically sent 69 to all receivers. 71 c. DVMRP builds a broadcast tree per source network with the routing 72 updates, so it doesn't have to flood links that are not part of 73 the broadcast tree for a source. 75 d. DVMRP uses its own topology discovery mechanism allowing both 76 faster adaptation to change and a more stable steady state. 78 e. Discovery mechanisms relying on expanding ring searches are fully 79 supported. 81 Of course, these benefits do not come without a cost. The broadcast 82 nature of DVMRP makes it unsuitable for connecting leaf domains via 83 low speed links. Additionally, the cost of keeping prune state for 84 unwanted data can be high depending on the mix of receivers. 86 Additionally, DVMRP operates on the premise that all data will be 87 broadcast throughout the domain and unwanted data will be pruned back 88 toward the source. If a DVMRP domain is connected downstream from an 89 explicit join multicast domain, then without additional mechanism, no 90 data would ever be broadcast into the DVMRP domain from the explicit 91 join domain. 93 2. Scalability/Applicability 95 A routing protocol need only scale within the limits of its intended 96 use. In this case, DVMRP need only scale within the context of 97 multicast routing domain or autonomous system. 99 There are several factors that limit the scalability of DVMRP. 100 Fortunately, these factors are well understood and by making these 101 explicit within this applicability statement, it should be possible 102 to avoid negative side-effects. 104 Convergence time 105 Since DVMRP uses a distance vector (also called Bellman-Ford after 106 its authors) routing algorithm to distribute source information, 107 its scope is limited by the convergence time required to propagate 108 updated source information across the routing domain. In order to 109 limit the convergence time, DVMRP has imposed a limit on the 110 number of hops across a domain by setting the infinity metric to 111 32 hops. 113 Count to Infinity 114 All distance vector protocols are susceptible to the well known 115 "count to infinity" problem [Perl92]. However, by requiring the 116 use of split horizon with poison reverse, the chances of 117 encountering this are significantly lowered. 119 3. State Analysis 121 As stated earlier, DVMRP broadcasts new multicast data to all 122 receivers and then prunes back the unwanted data based on group 123 membership information. To further reduce the amount of broadcasted 124 data, DVMRP builds the broadcast tree by determining the single 125 reverse path from a receiver back to the source and pruning duplicate 126 paths. 128 This truncated broadcast tree is precalculated using poison reverse 129 route updates as each router participates in a designated forwarder 130 election per source network to determine the upstream router. 132 This mechanism prevents duplicate datagrams from arriving on multi- 133 access networks at the expense of more state in the router. DVMRP 134 requires designated forwarder election state to be kept per prefix 135 per interface and prune state to be kept per neighbor per (group, 136 source prefix) pair. 138 4. Control Traffic Analysis 140 Independent of the amount of multicast data being forwarded, DVMRP 141 will always send some control traffic. First, there is a DVMRP probe 142 message sent every 10 seconds per interface for neighbor discovery 143 and keep-alive functions. Additionally, there are periodic route 144 exchanges that advertise source networks and assist in building the 145 multicast delivery trees. These route reports are resent every 60 146 seconds but are spread out across the report interval to reduce the 147 processing load. The number of route report packets sent is 148 dependent on the number of prefixes being reported. 150 The amount of prune and graft messages sent is a function of the 151 number of active senders and receivers for the data being forwarded. 152 Grafts are only sent to undo the effects of previous prunes. Prunes 153 are sent in response to unwanted multicast data. The lifetime of a 154 prune which is specific to a group and source network is 155 approximately 2 hours. This long lifetime greatly limits the amount 156 of prune control traffic that is sent. 158 5. References 160 [Perl92] Perlman, R., "Interconnections: Bridges and Routers", 161 Addison-Wesley, 1992, pp. 210-211. 163 [Pusa03] Pusateri, T., "Distance-Vector Multicast Routing Protocol 164 Version 3", Work In Progress, October 2003. 166 6. Author's Address 168 Thomas Pusateri 169 Juniper Networks, Inc. 170 1194 North Mathilda Avenue 171 Sunnyvale, CA 94089 USA 172 Phone: (408) 745-2000 173 EMail: pusateri@juniper.net 175 7. Acknowledgments 177 The author would like to acknowledge Dave Thaler, Bill Fenner, Thomas 178 Maufer, and Ravi Shekhar for their review and comments. 180 8. Full Copyright Statement 182 Copyright (C) The Internet Society 2004. All Rights Reserved. 184 This document and translations of it may be copied and furnished to 185 others, and derivative works that comment on or otherwise explain it 186 or assist in its implementation may be prepared, copied, published 187 and distributed, in whole or in part, without restriction of any 188 kind, provided that the above copyright notice and this paragraph are 189 included on all such copies and derivative works. However, this 190 document itself may not be modified in any way, such as by removing 191 the copyright notice or references to the Internet Society or other 192 Internet organizations, except as needed for the purpose of 193 developing Internet standards in which case the procedures for 194 copyrights defined in the Internet Standards process must be 195 followed, or as required to translate it into languages other than 196 English. 198 The limited permissions granted above are perpetual and will not be 199 revoked by the Internet Society or its successors or assigns. 201 This document and the information contained herein is provided on an 202 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 203 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 204 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 205 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 206 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 208 Table of Contents 210 1. Intended Use . . . . . . . . . . . . . . . . . . . . . . . . . 2 211 2. Scalability/Applicability . . . . . . . . . . . . . . . . . . 3 212 3. State Analysis . . . . . . . . . . . . . . . . . . . . . . . . 3 213 4. Control Traffic Analysis . . . . . . . . . . . . . . . . . . . 4 214 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 215 6. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 5 216 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 217 8. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 6