idnits 2.17.1 draft-crawley-mcast-rout-over-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 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 3 instances of lines with control characters in the document. ** The abstract seems to contain references ([2], [1]), 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 (February 22, 1996) is 10291 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) == Outdated reference: A later version (-11) exists of draft-ietf-ipatm-ipmc-09 -- No information found for draft-rekhter-pim-atm - is the name correct? -- Possible downref: Normative reference to a draft: ref. '2' == Outdated reference: A later version (-09) exists of draft-ietf-idmr-cbt-spec-04 ** Downref: Normative reference to an Historic draft: draft-ietf-idmr-cbt-spec (ref. '3') ** Downref: Normative reference to an Experimental RFC: RFC 1075 (ref. '4') ** Downref: Normative reference to an Historic RFC: RFC 1584 (ref. '5') -- Possible downref: Normative reference to a draft: ref. '6' == Outdated reference: A later version (-08) exists of draft-ietf-idmr-pim-dm-spec-01 -- Possible downref: Normative reference to a draft: ref. '7' == Outdated reference: A later version (-15) exists of draft-ietf-rsvp-spec-09 -- No information found for draft-ietf-rolc-nhrp- - is the name correct? -- Possible downref: Normative reference to a draft: ref. '9' Summary: 14 errors (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force E. Crawley 3 INTERNET-DRAFT Bay Networks 4 draft-crawley-mcast-rout-over-atm-00 February 22, 1996 6 Multicast Routing over ATM 8 Status of this Memo 10 This document is an Internet Draft. Internet Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its Areas, 12 and its Working Groups. Note that other groups may also distribute 13 working documents as Internet Drafts). 15 Internet Drafts are draft documents valid for a maximum of six 16 months. Internet Drafts may be updated, replaced, or obsoleted by 17 other documents at any time. It is not appropriate to use Internet 18 Drafts as reference material or to cite them other than as a "working 19 draft" or "work in progress." 21 Please check the I-D abstract listing contained in each Internet 22 Draft directory to learn the current status of this or any other 23 Internet Draft. 25 Abstract 27 As the use of IP multicasting and Asynchronous Transfer Mode (ATM) 28 technologies increases, it becomes important to think about ways that 29 IP multicast routing protocols interface to ATM networks. The 30 Multicast Address Resolution Server (MARS) [1] addresses the problem 31 of determining group membership within a single ATM Logical IP Subnet 32 (LIS) and provides a mapping between IP multicast addresses and ATM 33 addresses while [2] looks at the issues of short cut routing for PIM 34 Sparse Mode and CBT. In this document, the general problems of IP 35 multicast routing protocols over ATM networks are explored and the 36 issues related to the different forms of multicast routing protocols; 37 dense vs. sparse, shared tree vs. source tree, etc. are addressed. 38 Additionally, the issues related to short cut and QoS routing are 39 discussed. This document is intended as a starting point for 40 exploring the issues of IP multicast routing over ATM. 42 1. Introduction 44 Asynchronous Transfer Mode is a unique technology that provides some 45 features and challenges to layer 3 protocols that utilize it. While 46 ATM can be used to emulate traditional point-to-point links between 47 network nodes, it makes sense to utilize some of the additional 48 features of ATM if they can provide a benefit to the higher level 49 protocols. Some of the features in ATM can provide benefit to IP 50 multicast routing protocols. However, the benefits vary based on the 51 multicast routing protocol and the ATM features used. The way 52 different multicast routing protocols distribute data and control 53 information is very important when mapping to ATM. Further, there 54 are some additional issues that come up in ATM networks that need to 55 be addressed if such issues as short cut ATM paths, scaleability, and 56 Quality of Service (QoS) are considered. The issues and problems 57 presented are by no means a complete list but they are a starting 58 point for further discussion. 60 2. Data Plane and Control Plane 62 It is important to note the distinction between the control plane and 63 the data plane for IP multicast services. For IP multicasting in an 64 IP over ATM environment, the control plane is made up of an IP 65 multicasting protocol such as Core Based Trees (CBT)[3], Distance 66 Vector Multicast Routing Protocol (DVMRP)[4], Multicast Extensions to 67 OSPF (MOSPF)[5], Protocol Independent Multicasting-Sparse Mode 68 (PIM-SM)[6], Protocol Independent Multicasting-Dense Mode 69 (PIM-DM)[7], and optionally, MARS. The Internet Group Management 70 Protocol (IGMP) is not necessary over the ATM cloud but its presence 71 is not precluded. The control plane is responsible for setting up 72 the multicast tree and maintaining its state. In an IP over ATM 73 environment, the messages used to set up the tree may possibly be 74 forwarded over a different path than the multicast data. This issue 75 can become very important if the control data path is used for other 76 control protocols such as RSVP [8]. 78 The data plane in an IPATM environment consists of the virtual 79 circuits (VCs) that are involved in the actual forwarding multicast 80 data. These can either be point-to- point (pt-to-pt) or 81 point-to-multipoint (pt-to-mpt) VCs. The control plane can use the 82 same VCs but it may use a different set. Additionally, changes in 83 the control plane may cause changes in the VCs used in the data 84 plane. 86 3. Dense Mode and Sparse Mode 88 The exiting multicast routing protocols are divided into two classes, 89 dense mode and sparse mode. PIM-DM [7] and DVMRP [4] are dense mode 90 protocols and use a "broadcast and prune" model. Broadcast and prune 91 protocols forward data from senders to all subnets away from the 92 sender until a router indicates that it has no clients interested in 93 receiving the multicast by sending a control plane "prune" message 94 toward the sending router. Broadcast and prune protocols are best 95 suited to campus LAN environments where bandwidth is widely available 96 and simplicity of configuration is paramount. 98 In contrast, sparse mode protocols such as PIM-SM [6], MOSPF [5], and 99 CBT [3] use control plane messages for setting up multicast trees 100 such that data is only sent to the networks that have interested 101 receivers. Sparse mode protocols are used when the receivers are 102 widely dispersed. 104 Mapping these models to the Non-Broadcast MultiAccess (NBMA) 105 environment of ATM presents a bit of a problem. If ATM VCs are 106 considered "expensive," require a significant setup time, or a fully 107 interconnected mesh does not exist, then it may be best to use a 108 sparse mode protocol to avoid setting up VCs to destinations that may 109 not be interested in receiving the multicast data. Sparse mode 110 protocols can also make use of pt-to-pt VCs when transiting ATM 111 subnetworks that do not have any receivers. In contrast, 112 environments that consist mostly of permanent virtual circuits (PVCs) 113 can utilize dense mode or sparse mode protocols since there is no 114 dynamic set up cost. 116 4. Shared Trees and Source Trees 118 A further division of the exiting multicast routing protocols exists 119 in the type of multicast distribution tree that is created. A source 120 tree is "rooted" at the sender with a separate tree, and 121 corresponding state, for each sending network. A shared tree is 122 rooted at a node in the network with all senders using the same tree 123 for distribution of multicast data. The dense mode protocols, by 124 their very nature, create source trees. MOSPF and one mode of 125 operation for PIM-SM also use source trees. CBT and the other mode 126 of operation for PIM-SM use shared trees. Source trees and shared 127 trees present different problems when used over ATM. 129 Source trees more closely map the model of ATM pt-to-mpt VCs. This 130 makes them easier to visualize on the ATM network but presents more 131 scaleability problems regarding the use of VCs, depending on the 132 configuration. However, for a small number of senders per multicast 133 group, this is not an important issue. As the number of senders (and 134 corresponding ATM network ingress points) increases, the number of 135 pt-to-mpt VCs in the network increases. As the number of receivers 136 (and corresponding ATM network egress points) increases, each of the 137 pt-to-mpt VCs will require additional the additional ATM parties to 138 be added. 140 Shared trees, while requiring less state in the network, are more 141 likely to have multiple hops in the ATM network. It is quite 142 possible for a router on a shared tree in an ATM network to have 143 packets entering and exiting the same ATM interface if MARS or a 144 short-cutting mechanism such as NHRP is not used. 146 5. ATM Hosts and MARS 148 Naturally, any use of IP multicast routing over ATM has to take into 149 consideration hosts directly attached to the ATM network. MARS 150 essentially performs the function of IGMP for an ATM LIS and is 151 required, if there is a mix of hosts and routers on the ATM network. 152 If the ATM LIS is made up of only routers, it is possible to operate 153 without MARS but additional hops and packet copying may occur as 154 packets are routed through the ATM network. 156 If MARS is used, the ATM LIS looks like a multicast capable 157 subnetwork to the multicast routing protocol (see Figure 1). MARS 158 allows the multicast routing protocol to track the nodes on the ATM 159 LIS that are part of the multicast group and therefore can allow the 160 nodes to set up the appropriate pt-to-mpt VCs. 162 [Figure not in text version of document.] 163 Figure 1 165 The MARS specification also discusses the use of MARS in conjunction 166 with a ATM multicast server. A multicast server can be used to 167 relieve the burden of managing pt-to-mpt VCs for a router but incurs 168 a possible delay and bottleneck at the server. The issues and 169 performance of these configurations should be investigated further. 171 6. Short Cut Routing 173 The ability to make connections directly from a node on one ATM LIS 174 to a node on another ATM LIS, bypassing intermediate hops, is a very 175 attractive feature of ATM and other NBMA protocols. NHRP [9] 176 provides one mechanism for determining the ATM address of the egress 177 node in an ATM cloud based on the destination IP address. Of course, 178 this doesn't mean much if the destination address requested is an IP 179 multicast address so short cut mechanisms have to be used in concert 180 with a multicast routing protocol that can take advantage of the 181 abilities of the underlying unicast routing structure. This means 182 that PIM and CBT are best suited to the use of short cuts since they 183 are independent of the underlying unicast routing protocol. It is 184 unclear whether short cuts can be used with MOSPF or DVMRP but 185 warrants additional investigation. [2] describes how NHRP can be 186 used with PIM or CBT for building the multicast tree by using short 187 cuts from a joining node to a Core/Rendezvous Point (RP)/Source 188 Router 190 There are some possible problems that need to be thought through with 191 short cuts and their use with multicast routing. Some of these 192 problems can come from changes in the routing over time. These 193 problems need to be investigated fully before making widespread use 194 of short cuts with multicast routing. 196 There are also scaling issues for large multicasts when using short 197 cuts that need to be examined. Short cuts can cause a larger amount 198 of state to be stored in the nodes, from the additional short cut end 199 points, and can require larger fanouts for pt-to-mpt VCs. Depending 200 on the size of the ATM network, these can present problems. 202 7. Considerations for ATM VC Usage 204 ATM provides several different types of VCs and each has their own 205 properties, advantages, and disadvantages. In this section, the 206 implications of different types of VCs and their usage are discussed 207 in relation to IP multicast routing. This is not intended to be a 208 complete list. 210 7.1 Permanent Virtual Circuits (PVCs) 212 PVCs are the simplest form of ATM VCs and closely emulate common 213 pt-to-pt links. Obviously, these links can be easily used by IP 214 multicast routing and do not require any special treatment. 215 Multicast routers are likely to have multiple PVCs running out of the 216 same physical ATM interface and will have the extra burden copying 217 packets for each PVC even though the packets travel out of the same 218 physical interface. This is not the best use of resources but can be 219 tolerated for a relatively small number of PVCs. 221 7.2 Switched Virtual Circuits (SVCs) 223 SVCs allow for more dynamic connection setup but bring along the 224 burden of the time to setup the VCs and what to do with the data 225 during SVC setup. Additionally, a routing overlay is needed to 226 determine where to route SVCs. 228 For the moment, we can assume that an overlay of VCs exists to at 229 least some neighbors on he same LIS so that there is connectivity to 230 all the nodes on the LIS, albeit not necessarily one hop away. If a 231 node determines, perhaps via incoming data rates, that an SVC needs 232 to be established to a neighbor, it must continue to route data via 233 an indirect path until the SVC is setup or it will have to drop data. 234 These policies must be understood for multicast routing since the 235 first data arriving may be control messages to set up the tree and 236 dropping these messages may be catastrophic to tree setup. 238 The unicast routing that IP multicast routing protocols depend on 239 must be flexible enough to provide next hops in the ATM environment 240 such that SVCs can be set up as needed to get to a particular 241 destination. Further, it may be worthwhile to set up parallel VCs 242 especially when QoS is considered. 244 7.3 Point-to-Multipoint VCs 246 Point to multipoint (pt-to-mpt) VCs are the only way that ATM 247 networks can be used to replicate IP multicast data. This relieves 248 the router from duplicating data over multiple VCs. Of course, 249 point-to-multipoint VCs are unidirectional and come with a different 250 set of problems relating to management and scaling. 252 7.4 VC Fanout 254 An important consideration when dealing with pt-to-mpt VCs is the 255 number of destinations that can be supported. There may be limits in 256 the equipment in the ATM network that limit the number of parties on 257 a pt-to-mpt VC therefore it may be important to limit the fanout or 258 number of parties on a pt- to-mpt VC for IP multicasting. This is 259 especially true with large clouds where short cut routing is used. 261 7.5 VC Management 263 The MARS specification [1] discusses the issues of SVC management 264 with respect to a single multicast group but there are some 265 interesting issues that come up when dealing with multiple multicast 266 groups. For the most part, VC management is a local problem that 267 does not require standardization as long as a receiving node can 268 accept VCs from different ATM sources and an identical hop-wise path 269 can be made back to the ATM source node for use with protocols such 270 as RSVP [8]. 272 One method of managing multiple multicast groups is to assign each 273 group to a different pt-to-mpt VC but this limits the number of 274 groups that can be supported to the number of VCs available. A 275 second method looks for an existing pt-to-mpt VC that goes to the 276 same set of ATM destinations. If one is found the data is sent on 277 the VC. If not, a new VC is set up or multiple VCs that go to the 278 right set of ATM addresses can be used. This model can be extended 279 for further aggregation to include policies that would allow VCs that 280 go to a superset of the ATM destinations desired. Of course, this 281 method can quickly hit a point of diminishing returns, but can be 282 applied in cases where VCs are at a premium or a very large number of 283 multicast groups need to be supported. 285 7.6 ATM Hard State vs. Soft-State Protocols 287 ATM networks use reliable messaging and hard state connections. PIM 288 uses a soft state mechanism to periodically refresh multicast routing 289 state. [2] discusses reducing the frequency of the periodic soft 290 state messages when using PIM over ATM. The reasoning is that since 291 ATM provides a reliable hard state connection, with easy detection of 292 VC failure, there is a lesser need for soft state refresh messages to 293 detect the same kind of failures. Note, the soft state refresh 294 messages should not be eliminated because there are still classes of 295 failures that cannot be detected by the loss of a VC, such as the 296 failure of a process on an ingress or egress router. 298 CBT uses hard state with periodic echoing to determine neighbor 299 status. Over ATM, the frequency of these echoes can be reduced, if 300 necessary. MOSPF depends on link state changes as well as infrequent 301 hellos for state management so no changes would be necessary in this 302 respect when running over ATM. 304 8. ATM Futures that Impact Multicast Routing 306 The ATM Forum has been evolving the ATM specifications and some of 307 the changes currently planned and those being discussed can improve 308 the ability of IP multicast routing to run more effectively over ATM. 309 As these features become available, multicast routing should try to 310 take advantage of them. 312 8.1 Leaf Initiated Join 314 ATM Forum Release 4.0 contains a Leaf Initiated Join (LIJ) capability 315 to allow an ATM end point to join an existing pt- to-mpt VC without 316 necessarily contacting the root of the VC. This more closely matches 317 the receiver-based model of IP multicasting. There are issues about 318 determining the correct VC to join when a root can be managing 319 multiple and possibly parallel pt-to-mpt VCs that must be addressed 320 in order for this feature to be used. 322 8.2 Variegated Point-to-Multipoint 324 There have been discussions and contributions that consider the 325 possibility of a pt-to-mpt VC that would allow different QoS 326 parameters for each branch of the VC. This would be a benefit to 327 RSVP over ATM and multicast routing would need to know how to set up 328 and utilize such VCs. 330 8.3 Group Addressing 332 In order to make ATM multipoint communications more closely match the 333 IP multicast model, schemes that allow ATM group addresses that could 334 be directly mapped to IP multicast addresses have been discussed. 335 This is contrary to the traditional one-to-many communications of ATM 336 so it may take a bit of work to fit into the model. An important 337 issue is to make whatever scheme is developed be scaleable to the 338 needs of IP multicasting over ATM. 340 9. QoS Routing 342 Since ATM networks have QoS capabilities and these capabilities are 343 advertised in the PNNI (Private Network-to- Network Interface) 344 routing information, it makes sense for IP multicast routing over ATM 345 to make use of this information in concert with RSVP. The work in 346 this area is just starting but it will have an impact on multicast 347 routing, particularly over ATM. 349 10. Conclusions 351 In this draft, an initial attempt has been made at gathering, and 352 addressing, some of the issues related to IP multicast routing over 353 ATM. There are some areas that need to be documented and 354 investigated further. They include: 356 - The handling of control plane vs. data plane flows in ATM where 357 they can possibly follow different paths. 359 - The use of dense mode protocols in an ATM SVC environment 361 - The use of IGMP in an IP over ATM environment 363 - The impact of source tree vs. shared tree data distribution in ATM 365 - The impact of short cut routing for IP multicasting in ATM 367 - The impact of multicast servers on IP multicast routing 369 - Guidelines for VC management and usage for all multicast protocols 371 - Tweaking of soft-state mechanisms over ATM to reduce refresh 372 intervals 374 - Integrating new ATM features with multicast routing protocols 376 - The impact of multicast QoS routing schemes over ATM 378 These items should be considered as work items for the IDMR and IPATM 379 IETF working groups. 381 11. References 383 [1] G. Armitage, "Support for Multicast over UNI 3.0/3.1 based ATM 384 Networks", draft-ietf-ipatm-ipmc-09.txt, December 1995. 386 [2] Y. Rekhter, D. Farinacci, "Support for Sparse Mode PIM over ATM", 387 draft-rekhter-pim-atm-00.txt, February 1996. 389 [3] A. Ballardie, S. Reeve, N. Jain, "Core Based Trees (CBT) 390 Multicast-- Protocol Specification", draft-ietf-idmr- 391 cbt-spec-04.txt, February 1996. 393 [4] D. Waitzman, C. Partridge, S. Deering. "Distance Vector Multicast 394 Routing Protocol". RFC 1075, November 1988. 396 [5] J. Moy, Multicast Extensions to OSPF, RFC 1584, March 1994. 398 [6] S. Deering, D. Estrin, D. Farinacci, V. Jacobson, C. Liu, L.Wei, 399 P. Sharma, S. Helmy, "Protocol Independent Multicast-Sparse Mode 400 (PIM-SM): Protocol Specification", draft-ietf-idmr-pim-spec-02.txt, 401 September 1995. 403 [7] S. Deering, D. Estrin, D. Farinacci, V. Jacobson, C. Liu, L.Wei, 404 P. Sharma, S. Helmy, "Protocol Independent Multicast-Dense Mode 405 (PIM-DM): Protocol Specification", 406 draft-ietf-idmr-pim-dm-spec-01.txt, January 1996. 408 [8] R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin. "Resource 409 ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", 410 draft-ietf-rsvp-spec-09.txt, February 1996. 412 [9] D. Katz, D. Piscitello, B. Cole, J. Luciani, "NBMA Next Hop 413 Resolution Protocol (NHRP)", draft-ietf-rolc-nhrp- 07.txt, December 414 1995. 416 12. Author's Address 418 Eric S. Crawley 419 Bay Networks, Inc. 420 3 Federal Street 421 Billerica, MA 01821 422 +1 508 670-8888 423 esc@baynetworks.com