idnits 2.17.1 draft-bakre-mcast-atm-00.txt: 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-26) 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. ** 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 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 2 instances of lines with control characters in the document. 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 (November 1997) is 9659 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) == Unused Reference: '2' is defined on line 248, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 260, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 275, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 278, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' ** Downref: Normative reference to an Informational RFC: RFC 2121 (ref. '3') ** Downref: Normative reference to an Informational RFC: RFC 2191 (ref. '4') -- Possible downref: Non-RFC (?) normative reference: ref. '6' ** Downref: Normative reference to an Informational RFC: RFC 2098 (ref. '7') -- Possible downref: Non-RFC (?) normative reference: ref. '8' ** Downref: Normative reference to an Informational RFC: RFC 2149 (ref. '9') -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '11' -- Possible downref: Non-RFC (?) normative reference: ref. '12' Summary: 13 errors (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Ajay Bakre 2 File: draft-bakre-mcast-atm-00.txt Takeshi Nishida 3 Expiration: May 1998 C&C Research Labs 4 NEC USA, Inc. 5 November 1997 7 IP Multicast over ATM Networks with Cut-through Forwarding 8 for Inter LIS Traffic 10 Status of this Memo 12 This document is an Internet Draft. Internet Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its Areas, 14 and its Working Groups. Note that other groups may also distribute 15 working documents as Internet Drafts. 17 Internet Drafts are draft documents valid for a maximum of six 18 months. Internet Drafts may be updated, replaced, or obsoleted by 19 other documents at any time. It is not appropriate to use Internet 20 Drafts as reference material or to cite them other than as a 21 "working draft" or "work in progress." 23 To learn the current status of any Internet-Draft, please check the 24 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 25 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 26 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 27 ftp.isi.edu (US West Coast). 29 Abstract 31 This document proposes a scheme for IP multicasting in ATM networks, 32 which can achieve cut-through forwarding for inter LIS multicast 33 traffic using ATM protocols. 35 1. Introduction 37 The emergence of NHRP [8] as an alternative to hop-by-hop routing for 38 IP unicast traffic has given rise to hopes that a similar solution 39 can be developed for IP multicast as well. The problems associated 40 with extending multicast address resolution to the inter LIS case 41 have been well documented in [3] and [4]. In particular, scalability 42 and VC management issues make it impractical to extend multicast 43 address resolution to inter LIS multicast routing. 45 This document proposes an alternate scheme based on ATM protocols, 46 which can provide true shortcut paths for inter LIS multicast traffic 47 in a multi-LIS ATM cloud. By true shortcut paths we mean the paths 48 resulting from the use of ATM signaling without regard to the way 49 LISs are interconnected. The proposed scheme is described informally. 50 The primary goal of this document is to encourage a renewed 51 discussion on the feasibility of cut-through forwarding for inter LIS 52 multicast traffic. 54 2. Proposed Scheme 56 The proposed IP multicasting scheme is based on multicast switches. 57 A multicast switch is somewhat similar to a switch-router in the 58 sense that it is capable of packet level forwarding as well as cell 59 level forwarding. However, a multicast switch also has some important 60 differences from a switch-router. First, unlike a router, which can 61 be a part of multiple LISs, a multicast switch is part of exactly one 62 LIS. Thus instead of multiple IP interfaces, a multicast switch 63 essentially has only two "sides" - on one are the IP/ATM hosts within 64 its LIS, on the other are all other multicast switches and IP/ATM 65 hosts in the ATM cloud. Second, instead of using one of the IP based 66 multicast routing protocols for hop-by-hop forwarding of multicast 67 traffic, multicast switches treat the ATM cloud as a shared network 68 where each multicast switch is just one hop away from all other 69 multicast switches. 71 Using the features mentioned above allows achieving many important 72 objectives. First, it allows aggregation of receivers inside an LIS, 73 these receivers being represented in the ATM cloud by the multicast 74 switch in the LIS. Second, for inter-LIS multicast forwarding, VCs 75 are established among multicast switches using ATM signaling giving 76 true shortcuts regardless of how individual LISs are interconnected. 77 Third, multicast switches can concatenate intra LIS VCs with inter 78 LIS VCs to achieve cut-through forwarding through those switches. 79 Fourth, multicast forwarding within the ATM cloud can be separated 80 from the traditional routing considerations of "reverse shortest 81 path". This greatly simplifies inter LIS multicast forwarding. 83 3. Intra LIS Multicasting 85 For multicasting within an LIS, the designated multicast switch in 86 the LIS can also function as a multicast server (MCS), albeit with 87 an important difference. Unlike the MCS proposed in [9], which only 88 uses packet level forwarding, a multicast switch can support both 89 cell level and packet level forwarding. Which method is used for a 90 given multicast group depends on considerations such as the number of 91 senders and receivers for that group within the LIS and the need for 92 QoS based multicast using RSVP. A multicast switch thus takes over 93 the VC management function from individual senders, but leaves the 94 option open for either concentrating the traffic from multiple 95 senders on a single point to multipoint intra-LIS data VC or 96 establishing a separate VC for each sender. As an example, if the 97 number of senders within the LIS is small, separate VC trees may be 98 established for each sender by the multicast switch (also see the 99 section on QoS considerations below). 101 4. Inter LIS Multicasting 103 For multicasting across LIS boundaries, multicast switches in 104 individual LISs form a control tree among themselves. This control 105 tree may consist of point to multipoint VCs, one rooted at each 106 multicast switch with all other multicast switches added as leaves. 107 Another possibility is to have a mesh of point to point VCs 108 interconnecting pairs of multicast switches, which may be the method 109 of choice for QoS multicast (see the section on QoS considerations). 110 Scalability issues are considered in another section later. A 111 multicast switch can learn about other multicast switches in the ATM 112 cloud through various mechanisms, e.g. by tagging and propagating 113 such information via PNNI updates. 115 The control tree is used by multicast switches to exchange group 116 membership information about their respective LISs. Multicast 117 switches can learn about the existence of senders and receivers 118 within their LISs from their local MARSs. On discovering a sender 119 within its LIS, a multicast switch can learn about the existence of 120 receivers in other LISs from the information exchanged with other 121 multicast switches in the ATM cloud. To form an inter LIS multicast 122 tree, a multicast switch that has a sender within its LIS, 123 establishes a point to multipoint data VC to all other multicast 124 switches that have receivers within their LISs. ATM signaling is used 125 to establish the inter LIS VC ensuring true shortcut paths to all 126 downstream multicast switches. Multicast switches added as leaves to 127 this inter LIS VC in turn form intra LIS data VCs within their 128 respective LISs for distribution of the multicast traffic originating 129 at senders within as well as outside their LISs. Whether a multicast 130 switch aggregates traffic from multiple senders within its LIS on a 131 single outgoing inter LIS VC or whether different inter LIS VCs are 132 formed for each local sender, can be decided by individual switches. 133 The latter method allows cell level forwarding and may be suitable 134 for QoS traffic, but can be wasteful if the number of senders in an 135 LIS is large. Downstream (receiving) multicast switches in turn 136 determine how to distribute traffic from multiple senders (both local 137 and external). The alternatives range from aggregating all traffic 138 for local receivers on a single intra LIS VC to having a separate VC 139 for each sender. 141 If separate intra and inter LIS VCs are established by each multicast 142 switch for each sender, individual multicast switches can concatenate 143 incoming and outgoing VCs to form a complete multicast tree for each 144 sender. This allows cell level (cut-through) forwarding from the 145 sender to all the receivers. Any aggregation of senders on the other 146 hand, will involve packet level forwarding at the point of 147 aggregation to prevent cell interleaving, although no routing lookup 148 is needed at the multicast switches once the VCs are established. 150 5. Interoperation with External Mrouters 152 Interoperation with Mrouters outside the ATM cloud is achieved by 153 edge multicast switches. A multicast switch configured as an edge 154 switch participates in one or more IDMR protocols that may be in 155 use on its non-ATM interfaces. In addition, all edge switches in 156 an ATM cloud cooperate to partition the external networks in a way 157 that allows one of the edge switches to become the designated 158 forwarder for each external subnet (or IP network). What this means 159 is that if traffic from an outside sender arrives at one or more 160 edge switches, only one of them (the designated forwarder for the 161 sender's subnet) will establish an inter LIS data tree within the 162 ATM cloud. All the edge switches can forward traffic originating 163 inside the ATM cloud to outside Mrouters however. This includes 164 multicast traffic that uses the ATM cloud as a transit network 165 (possibly with some receivers in the ATM cloud as well). 167 6. Scalability Issues for Multicast Switches 169 If the number of LISs (and multicast switches) in an ATM cloud is 170 large, the requirement in the proposed scheme that each multicast 171 switch exchange multicast group membership information with all other 172 multicast switches in the ATM cloud, may be hard to implement. In 173 such a case, a hierarchy of multicast switches analogous to the PNNI 174 hierarchy may be used such that multicast switches in a PNNI domain 175 exchange complete group membership information with each other, but 176 only summarized information is exchanged at the higher levels. In 177 such a case, an inter LIS multicast tree will consist of individual 178 inter LIS trees in each PNNI domain together with any VCs required to 179 interconnect such trees across domain boundaries. One proposal for 180 using the PNNI hierarchy for multicasting in ATM networks can be 181 found in [10]. 183 7. QoS Considerations 185 To support IP Integrated Services over ATM networks using RSVP [5], 186 multicast switches also provide termination points for RSVP messages 187 originating in their respective LISs. Aggregate QoS requests based on 188 RESV messages from individual LISs can be forwarded to one or more 189 multicast switches that have local senders. These multicast switches 190 can then establish inter LIS data VCs with sufficiently large QoS 191 parameters, to satisfy all downstream reservations. 193 Additional control VCs are needed within each LIS for propagating 194 RSVP control messages. A single point to multipoint control VC from 195 a multicast switch to all registered multicast receivers in an LIS 196 can be shared by all multicast groups for the distribution of PATH 197 messages from local and external senders. QoS receivers will need 198 additional point to point control VCs to send RESV messages back to 199 the local multicast switch. 201 8. Related Work 203 Cell switch routers (CSRs) [7] can provide shortcut paths through 204 IP routers. One problem associated with CSRs is that simple 205 concatenation of intra LIS VCs does not necessarily yield a true 206 shortcut path from a sender to one or more receivers, as these VCs 207 are formed individually using IP routing information. Another scheme 208 proposed for shortcut multicast routing is the IMSS proposal [1], 209 which uses two different protocols, namely CONGRESS and IP-SENATE, to 210 resolve IP multicast addresses to ATM addresses of downstream routers 211 and to establish inter-LIS shortcut paths to such routers. This 212 scheme consists of fairly complex protocols and attempts to solve a 213 very general problem of IP multicasting in ATM, using a mix of 214 routers that are capable of shortcut forwarding as well as hop-by-hop 215 forwarding. By contrast, the scheme proposed in this document focuses 216 on providing a simple shortcut forwarding solution for inter LIS 217 multicast traffic in an ATM cloud that uses IDMR protocols only at 218 the edge switches. 220 9. Conclusion 222 A scheme for IP multicasting was proposed in this document that 223 allows cut-through forwarding of inter LIS multicast traffic. The 224 scheme is based on multicast switches and includes methods of 225 establishing intra and inter LIS VCs for data and control traffic. 227 10. Security Considerations 229 Security considerations are not addressed in this document. 231 11. Intellectual Property Considerations 233 NEC may seek patent or other intellectual property protection for 234 some aspects discussed in this document. 236 12. Acknowledgments 238 The authors have benefitted from discussions with the following 239 persons in preparing this document: Dipankar Raychaudhuri, Arup 240 Acharya, Rajiv Dighe, Kunihiro Taniguchi, Hirohito Sakamoto and Bala 241 Rajagopalan. 243 13. References 245 [1] Anker, T., et al., "IMSS: IP Multicast Shortcut Service", Work 246 in Progress, July 1997. 248 [2] Armitage, G., "Support for Multicast over UNI 3.0/3.1 based ATM 249 Networks", RFC 2022, November 1996. 251 [3] Armitage, G., "Issues affecting MARS Cluster Size", RFC 2121, 252 March 1997. 254 [4] Armitage, G., "VENUS - Very Extensive Non-Unicast Service", RFC 255 2191, September 1997. 257 [5] Braden, R., et al., "Resource ReSerVation Protocol (RSVP) -- 258 Version 1 Functional Specification", RFC 2205, September 1997. 260 [6] Crawley, E., et al., "A Framework for Integrated Services and 261 RSVP over ATM", Work in Progress, November 1997. 263 [7] Katsube, Y., et al., "Toshiba's Router Architecture Extensions 264 for ATM : Overview", RFC 2098, February 1997. 266 [8] Luciani, J., et al., "NBMA Next Hop Resolution Protocol (NHRP)", 267 Work in Progress, September 1997. 269 [9] Talpade, R. and Ammar, M., "Multicast Server Architectures for 270 MARS-based ATM multicasting", RFC 2149, May 1997. 272 [10] Venkateswaran, R. and Raghavendra, C.S., "Hierarchical Multicast 273 Routing in Wide-Area ATM Networks", Proc. ICC '96, June 1996. 275 [11] ATM Forum, "ATM User-Network Interface (UNI) Signalling 276 Specification Version 4.0", af-sig-0061.000, July, 1996. 278 [12] ATM Forum PNNI subworking group, "Private Network-Network 279 Interface Specification Version 1.0 (PNNI 1.0)", afpnni-0055.000, 280 March 1996. 282 14. Authors' Addresses 284 Ajay Bakre 285 C&C Research Labs, NEC USA, Inc. 286 110 Rio Robles, San Jose 287 CA 95132, USA. 288 Phone: +1-408-943-3034 289 Email: bakre@ccrl.sj.nec.com 291 Takeshi Nishida 292 C&C Research Labs, NEC USA, Inc. 293 110 Rio Robles, San Jose 294 CA 95132, USA. 295 Phone: +1-408-943-3030 296 Email: nishida@ccrl.sj.nec.com