idnits 2.17.1 draft-ietf-ion-intralis-multicast-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): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-03-29) 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 5 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 6 pages -- Found 6 instances of the string 'FORMFEED[Page...' -- is this a case of missing nroff postprocessing? 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 (April 1997) is 9845 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 (==), 5 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: October 1997 April 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 router within a LIS is required to maintain a single (shared) 61 router distribution point-to-multipoint VC rooted at the router with 62 all other routers in the LIS as the leaf nodes of that VC. 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 65 would be used for distributing PIM [PIM-SM] control messages 66 (Join/Prune messages). 68 4.1. Establishing Dedicated, Per Group Point-to-Multipoint VCs 70 Routers may also maintain group specific, dedicated point-to- 71 multipoint VCs. In particular, an upstream router for a group may 72 choose to become the root of a group specific point-to-multipoint VC 73 whose leaves are the downstream routers that have directly connected 74 or downstream receivers for the group. While the criteria for 75 establishing a group specific point-to-multipoint VC are local to a 76 router, issues such as the volume of traffic associated with the 77 group and the fanout factor within the LIS should be considered. 78 Finally, note that a router must minimally support a single shared 79 point-to-multipoint VC for distribution of control messages and data 80 (to all group addresses). 82 A router can choose to establish a dedicated point-to-multipoint VC 83 (or add another leaf to an already established dedicated point-to- 84 multipoint VC) when it receives a PIM Join messages from another 85 router in the same LIS. The router sending the joins uses its shared 86 point-to-multipoint VC. Similarly, when a router that is the root of 87 a point-to-multipoint VC receives PIM Prune message, it removes the 88 originator of the message from its dedicated point-to-multipoint VC. 90 4.2. Switching to a Source-Rooted Tree 92 If at least one of the routers within a LIS decides to switch to a 93 source-rooted tree (by sending (S,G) PIM Joins), then all other 94 routers within the LIS that have downstream members for G should 95 switch to that source-rooted tree as well. Since a router that 96 switches to a source-rooted tree sends PIM Join messages for (S,G) 97 over its shared point-to-multipoint VC, the other routers within the 98 LIS are able to detect this. Once a router that has downstream 99 members for G detects this, the router should send (S,G) PIM Join 100 message as well (otherwise the router may receive duplicate traffic 101 from S). 103 4.2.1. Adding New Members to a Source-Rooted Tree 105 As mentioned above, this document requires that once one router in a 106 LIS decides to switch to the source tree for some (S,G), all routers 107 in the LIS that have downstream members must also switch to the (S,G) 108 source tree. Now, when a new router wants to receive traffic from G, 109 it starts sending (*,G)-Joins on it's shared point-to-multipoint VC 110 toward the RP for G. The root of the (S,G)-source-rooted tree will 111 know to add the new router to the point-to-multipoint VC servicing 112 the (S,G)-source-rooted tree by observing the (*,G)-joins on it's 113 shared point-to-multipoint VC. However, the new router must also 114 switch to the (S,G)-source-rooted tree. In order to accomplish this, 115 the newly added router must: 117 (i). Notice that it has been added to a new 118 point-to-multipoint VC 120 (ii). Notice (S,G) traffic coming down this new 121 point-to-multipoint VC 123 (iii). Send (S,G) joins toward S, causing it to switch to the 124 source-rooted tree. The router learns that the VC is 125 used to distribute (S,G) traffic in the previous 126 steps. 128 4.3. Handing the "Packet Reflection" Problem 130 When a router receives a multicast packet from another router in its 131 own LIS, the router should not send the packet on any of the routers 132 distribution point-to-multipoint VCs associate with the LIS. This 133 eliminates the problem of "packet reflection". Sending the packet on 134 the routers' distribution VCs associated with other LISs is 135 controlled by the multicast routing procedures. 137 5. Brief Comparison with MARS 139 The intra-LIS multicast scheme described in this document is intended 140 to be a less complex solution to an important subset of the 141 functionality provided by the Multicast Address Resolution Server, or 142 MARS [MARS]. In particular, it is designed to provide intra-LIS 143 multicast between routers using PIM-SM, and does not consider the 144 case of host-rooted point-to-multicast multicast distribution VCs. 146 Although MARS supports both of the current schemes for mapping the IP 147 multicast service model to ATM (multicast server and meshes of 148 point-to-multipoint VCs), it does so at at cost and complexity higher 149 than of the scheme described in this document. In addition, MARS 150 requires new encapsulations, whereas this proposal works with either 151 LLC/SNAP or with NLPID encapsulation. Another important difference is 152 that MARS allows point-to-multipoint VCs rooted either at a source or 153 at a multicast server (MCS). The approach taken here is to constrain 154 complexity by focusing on PIM-SM (taking advantage of information 155 available in explicit joins), and by allowing point-to-multipoint VCs 156 to be rooted only at the routers (which is roughly analogous to the 157 complexity and functionality of rooting point-to-multipoint VCs at 158 the sources). 160 In summary, the method described in this document is designed for the 161 router-to-router case, and takes advantage of the explicit-join 162 mechanism inherent in PIM-SM to provide a simple mechanism for 163 intra-LIS multicast between routers. MARS, on the other hand, accepts 164 different tradeoffs in complexity-functionality design space. In 165 particular, while the MARS paradigm provides a general neighbor 166 discovery mechanism, allows host to participate, and is protocol 167 independent, it does so at considerable cost. 169 6. Security Considerations 171 Security issues are not discussed in this document. 173 7. References 175 [MARS] G. Armitage, "Support for Multicast over UNI 176 3.0/3.1 based ATM Networks.", RFC2022, November 177 1996. 179 [PIM-SM] Estrin, D, et. al., "Protocol Independent Multicast 180 Sparse Mode (PIM-SM): Protocol Specification", 181 draft-ietf-idmr-PIM-SM-spec-09.ps, October, 1996. 183 8. Acknowledgments 185 To be supplied. 187 9. Author Information 189 Dino Farinacci 190 Cisco Systems 191 170 Tasman Dr. 192 San Jose, CA 95134 193 Phone: (408) 526-4696 194 e-mail: dino@cisco.com 196 David Meyer 197 University of Oregon 198 1225 Kincaid St. 199 Eugene, OR 97403 200 Phone: (541) 346-1747 201 e-mail: meyer@antc.uoregon.edu 203 Yakov Rekhter 204 cisco Systems, Inc. 205 170 Tasman Dr. 206 San Jose, CA 95134 207 Phone: (914) 528-0090 208 email: yakov@cisco.com