idnits 2.17.1 draft-ietf-ion-intralis-multicast-01.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): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-20) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** 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? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 4 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 5 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 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. ** The abstract seems to contain references ([PIM-SM]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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.) -- The document date (August 1997) is 9745 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: 'RFC1577' is mentioned on line 57, but not defined ** Obsolete undefined reference: RFC 1577 (Obsoleted by RFC 2225) -- No information found for draft-ietf-idmr-PIM-SM-spec - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'PIM-SM' Summary: 12 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Dino Farinacci 3 Internet Draft Cisco Systems 4 David Meyer 5 University of Oregon 6 Yakov Rekhter 7 Cisco Systems 9 Expiration Date: February 1997 August 1997 11 Intra-LIS IP multicast among routers over ATM using Sparse Mode PIM 13 15 1. Status of this Memo 17 This document is an Internet-Draft. Internet-Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its areas, 19 and its working groups. Note that other groups may also distribute 20 working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as ``work in progress.'' 27 To learn the current status of any Internet-Draft, please check the 28 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 29 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 30 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 31 ftp.isi.edu (US West Coast). 33 2. Abstract 35 This document describes how intra-LIS IP multicast can be efficiently 36 supported among routers over ATM without using the Multicast Address 37 Resolution Server (MARS). The method described here is specific to 38 Sparse Mode PIM [PIM-SM], and relies on the explicit join mechanism 39 inherent in PIM-SM to notify routers when they should create group 40 specific point-to-multipoint VCs. 42 3. Overall model 44 This document focuses on forwarding of multicast traffic among PIM-SM 45 routers connected to an ATM network. Routers on an ATM network are 46 partitioned into Logical IP Subnets, or LISs. This document deals 47 with handling multicast within a single LIS. Handling inter-LIS 48 multicast traffic, including handling shortcuts, is outside the scope 49 of this document. In addition, this document does not address 50 forwarding of multicast traffic to or from hosts connected to an ATM 51 network. 53 4. Router behavior 55 This document requires that each router within a LIS knows IP and ATM 56 addresses of all other routers within the LIS. The mapping between IP 57 and ATM addresses may be provided by an ARP server [RFC1577], or by 58 any other means (e.g., static configuration). 60 Each PIM router within a LIS is required to maintain a single 61 (shared) point-to-multipoint distribution VC rooted at the router 62 with all other PIM routers in the LIS as the leaf nodes. The VC is 63 expected to be used for forwarding of multicast traffic (both data 64 and control) among routers within the LIS. For example, this VC would 65 be used for distributing PIM [PIM-SM] control messages (Join/Prune 66 messages). 68 In addition, if a PIM router receives a IGMP report from an non-PIM 69 neighbor, then the router may add the reporter to the existing shared 70 distribution VC or to the group specific distribution VC (if it 71 exists). The PIM router may also create a specific VC for this IGMP 72 proxy. 74 4.1. Establishing Dedicated, Per Group Point-to-Multipoint VCs 76 Routers may also maintain group specific, dedicated point-to- 77 multipoint VCs. In particular, an upstream router for a group may 78 choose to become the root of a group specific point-to-multipoint VC 79 whose leaves are the downstream routers that have directly connected 80 or downstream receivers for the group. While the criteria for 81 establishing a group specific point-to-multipoint VC are local to a 82 router, issues such as the volume of traffic associated with the 83 group and the fanout factor within the LIS should be considered. 84 Finally, note that a router must minimally support a single shared 85 point-to-multipoint VC for distribution of control messages and data 86 (to all group addresses). 88 A router can choose to establish a dedicated point-to-multipoint VC 89 (or add another leaf to an already established dedicated point-to- 90 multipoint VC) when it receives a PIM Join or IGMP report messages 91 from another device in the same LIS. When a router that is the root 92 of a point-to-multipoint VC receives PIM Prune message or IGMP leave, 93 it removes the originator of the message from its dedicated point- 94 to-multipoint VC. 96 4.2. Switching to a Source-Rooted Tree 98 If at least one of the routers within a LIS decides to switch to a 99 source-rooted tree (by sending (S,G) PIM Joins), then all other 100 routers within the LIS that have downstream members for G should 101 switch to that source-rooted tree as well. Since a router that 102 switches to a source-rooted tree sends PIM Join messages for (S,G) 103 over its shared point-to-multipoint VC, the other routers within the 104 LIS are able to detect this. Once a router that has downstream 105 members for G detects this, the router should send (S,G) PIM Join 106 message as well (otherwise the router may receive duplicate traffic 107 from S). 109 Note that it is possible for a non-PIM router in the LIS to fail to 110 receive data if the injection point moves to router to which there is 111 not an existing VC. 113 4.2.1. Adding New Members to a Source-Rooted Tree 115 As mentioned above, this document requires that once one router in a 116 LIS decides to switch to the source tree for some (S,G), all routers 117 in the LIS that have downstream members must also switch to the (S,G) 118 source tree. Now, when a new router wants to receive traffic from G, 119 it starts sending (*,G)-Joins on it's shared point-to-multipoint VC 120 toward the RP for G. The root of the (S,G)-source-rooted tree will 121 know to add the new router to the point-to-multipoint VC servicing 122 the (S,G)-source-rooted tree by observing the (*,G)-joins on it's 123 shared point-to-multipoint VC. However, the new router must also 124 switch to the (S,G)-source-rooted tree. In order to accomplish this, 125 the newly added router must: 127 (i). Notice that it has been added to a new 128 point-to-multipoint VC 130 (ii). Notice (S,G) traffic coming down this new 131 point-to-multipoint VC 133 (iii). Send (S,G) joins toward S, causing it to switch to the 134 source-rooted tree. The router learns that the VC is 135 used to distribute (S,G) traffic in the previous 136 steps. 138 4.3. Handing the "Packet Reflection" Problem 140 When a router receives a multicast packet from another router in its 141 own LIS, the router should not send the packet on any of the routers 142 distribution point-to-multipoint VCs associate with the LIS. This 143 eliminates the problem of "packet reflection". Sending the packet on 144 the routers' distribution VCs associated with other LISs is 145 controlled by the multicast routing procedures. 147 5. Brief Comparison with MARS 149 The intra-LIS multicast scheme described in this document is intended 150 to be a less complex solution to an important subset of the 151 functionality provided by the Multicast Address Resolution Server, or 152 MARS [MARS]. In particular, it is designed to provide intra-LIS 153 multicast between routers using PIM-SM, and does not consider the 154 case of host-rooted point-to-multicast multicast distribution VCs. 156 Although MARS supports both of the current schemes for mapping the IP 157 multicast service model to ATM (multicast server and meshes of 158 point-to-multipoint VCs), it does so at at cost and complexity higher 159 than of the scheme described in this document. In addition, MARS 160 requires new encapsulations, whereas this proposal works with either 161 LLC/SNAP or with NLPID encapsulation. Another important difference is 162 that MARS allows point-to-multipoint VCs rooted either at a source or 163 at a multicast server (MCS). The approach taken here is to constrain 164 complexity by focusing on PIM-SM (taking advantage of information 165 available in explicit joins), and by allowing point-to-multipoint VCs 166 to be rooted only at the routers (which is roughly analogous to the 167 complexity and functionality of rooting point-to-multipoint VCs at 168 the sources). 170 In summary, the method described in this document is designed for the 171 router-to-router case, and takes advantage of the explicit-join 172 mechanism inherent in PIM-SM to provide a simple mechanism for 173 intra-LIS multicast between routers. MARS, on the other hand, accepts 174 different tradeoffs in complexity-functionality design space. In 175 particular, while the MARS paradigm provides a general neighbor 176 discovery mechanism, allows host to participate, and is protocol 177 independent, it does so at considerable cost. 179 6. Security Considerations 181 Security issues are not discussed in this document. 183 7. References 185 [MARS] G. Armitage, "Support for Multicast over UNI 186 3.0/3.1 based ATM Networks.", RFC2022, November 187 1996. 189 [PIM-SM] Estrin, D, et. al., "Protocol Independent Multicast 190 Sparse Mode (PIM-SM): Protocol Specification", 191 draft-ietf-idmr-PIM-SM-spec-09.ps, October, 1996. 193 8. Acknowledgments 195 Petri Helenius provided several insightful comments on earlier 196 versions of this document. 198 9. Author Information 199 Dino Farinacci 200 Cisco Systems 201 170 Tasman Dr. 202 San Jose, CA 95134 203 Phone: (408) 526-4696 204 e-mail: dino@cisco.com 206 David Meyer 207 University of Oregon 208 1225 Kincaid St. 209 Eugene, OR 97403 210 Phone: (541) 346-1747 211 e-mail: meyer@antc.uoregon.edu 213 Yakov Rekhter 214 cisco Systems, Inc. 215 170 Tasman Dr. 216 San Jose, CA 95134 217 Phone: (914) 528-0090 218 email: yakov@cisco.com