idnits 2.17.1 draft-ietf-mboned-mix-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): ---------------------------------------------------------------------------- ** 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: ---------------------------------------------------------------------------- ** 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 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 == It seems as if not all pages are separated by form feeds - found 0 form feeds but 10 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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: 'DVMRP' is defined on line 336, but no explicit reference was found in the text == Unused Reference: 'PIM-DM' is defined on line 354, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'DVMRP' ** Obsolete normative reference: RFC 2362 (ref. 'PIM-SM') (Obsoleted by RFC 4601, RFC 5059) -- Possible downref: Non-RFC (?) normative reference: ref. 'PIM-DM' -- Possible downref: Non-RFC (?) normative reference: ref. 'MSDP' Summary: 8 errors (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MBONED Working Group Hugh LaMaster 2 Internet Draft Steve Shultz 3 NASA ARC/NREN 4 John Meylor 5 David Meyer 6 Cisco Systems 8 Category Informational 9 draft-ietf-mboned-mix-01.txt June, 1999 11 Multicast-Friendly Internet Exchange (MIX) 13 1. Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC 2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet- Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 2. Abstract 36 This document describes an architecture for a Multicast-friendly 37 Internet eXchange (MIX), and the actual implementation at the NASA 38 Ames Research Center Federal Internet eXchange (FIX-West, or FIX). 39 The MIX has three objectives: native IP multicast routing, scalable 40 interdomain policy-based route exchange, and to allow a variety of 41 IGP protocols and topologies for intra-domain use. In support of 42 these objectives, the MIX architecture defines the following 43 components: a peer-peer routing protocol, a method for multicast 44 forwarding, a method for exchanging information about active sources, 45 and a medium which provides native multicast. This document 46 describes the protocols and configurations necessary to provide a 47 current, working multicast-friendly internet exchange, or MIX. 49 This memo is a product of the MBONE Deployment Working Group (MBONED) 50 in the Operations and Management Area of the Internet Engineering 51 Task Force. Submit comments to or the 52 authors. 54 Acknowledgments 56 Thanks to the NASA HPCC program for supporting the NREN staff portion 57 of this project; thanks to William P. Jones of the NASA ARC Gateway 58 Facility for making the gateway facility available for housing this 59 project. 61 3. Copyright Notice 63 Copyright (C) The Internet Society (1999). All Rights Reserved. 65 4. Introduction 67 The MIX objective was to use current technology to implement a 68 scalable, high-performance, efficient, native IP multicast 69 architecture. 71 Past experience at ARC, NASA WANs, and at FIX-West, had shown that 72 mrouted/DVMRP "Mbone" tunnels were an inefficient of routing 73 multicast through an exchange point. Specifically, at FIX-West, the 74 large number of tunnels often resulted in unicast traffic loads on 75 the FIX FDDI that were 10 times the underlying multicast load. In 76 addition, some WANs had multiple tunnels criss-crossing the same 77 physical links, resulting in wasted WAN bandwidth. And, the separate 78 workstation and router infrastructure for the "Mbone" tunnels created 79 numerous problems. Maintenance of Unix system and tunnel 80 configurations was often ad hoc, because some of the network 81 operators lacked the necessary expertise. And the hardware and 82 software configuration and performance of the tunnel infrastructure 83 was often out of step with the underlying router-based unicast 84 structure. In addition, use of a single, shared, distance-vector IGP 85 in the inter-domain space led to instability. 87 Therefore, it was desired to implement a new multicast internet 88 exchange from the ground up, using current technology, and 89 significantly improving performance, efficiency, and reliability. 91 Four elements were identified as being necessary for the MIX 92 architecture in order to meet the objectives. These were to define a 93 peer-peer routing protocol, a method for multicast forwarding, a 94 method for exchanging information about distant sources and groups, 95 and a non-switched broadcast medium. 97 NASA Ames Research Center hosts the Federal Internet eXchange (FIX- 98 West, or, "the FIX") as well as hosting the Ames Internet eXchange 99 (AIX), which is connected at high speed to the MAE-West, and, which 100 also shares the same address space as the MAE-West. These facilities 101 are co-located at the Ames Telecommunications Gateway Facility. It 102 was felt that this would be an excellent location to test the 103 viability of the native multicast technologies. The Multicast- 104 friendly Internet eXchange (MIX) is co-located adjacent to the FIX 105 for easy access from the existing FIX routers. 107 Choices were made for each element, and the MIX was implemented 108 adjacent to the existing NASA ARC FIX gateway facility. At the time 109 of writing, there are eight direct participants in the MIX, peering 110 and exchanging routes and multicast traffic natively, and the 111 performance and reliability have already far exceeded the tunneled 112 infrastructure the MIX replaced. 114 5. Requirements and Technology 116 In order to meet the objectives for this multicast exchange, all 117 peering partners had to agree mutually to standardize on the 118 following four elements. These are: 120 - the protocol to be used for multicast route exchange 121 - the method for performing multicast forwarding 122 - the method for identifying active sources 123 - the physical medium for the multicast exchange 125 The elements chosen to implement the MIX were BGP4+ (also known as 126 "MBGP") for routing and route exchange [BGP4+], PIM-SM for multicast 127 forwarding on the exchange, the MSDP protocol for information on 128 sources and groups, and, FDDI for the multicast medium. 130 5.1. Routing 132 Two of the objectives of the MIX were to provide an EGP for scalable 133 interdomain policy-based route exchange, and to allow a variety of 134 IGP protocols and topologies for intra-domain use. As with unicast 135 interdomain routing, BGP could be used as the EGP to exchange routes 136 for multicast. However, the unicast and multicast routing paths and 137 policies would have to be completely congruent. In practice, this is 138 sometimes not the case. It is possible, however, to take advantage 139 of the extensions in BGP4+ to deal with these policy and path 140 incongruencies. 142 BGP4+ [BGP4+] describes extensions to (unicast) BGP that allow use of 143 the existing BGP machinery to provide the necessary scalability, 144 policy control, and route stability features and mechanisms to be 145 applied to both unicast and multicast routes consistently. 147 BGP4+ allows routes to be marked "unicast forwarding", "multicast 148 forwarding", or "both unicast and multicast forwarding". In this 149 way, BGP4+ supports different multicast and unicast forwarding paths 150 and policies. This removes the dependency on unicast-only routing. 152 The ability of BGP4+ to support separate paths and policies for 153 multicast is important for meeting the objectives of the exchange in 154 various ways. It allows for a participant's multicast routing policy 155 to be independent of its established unicast routing policy. This is 156 important in order that the exchange can support providers migrating 157 to BGP4+ as an IDMR. This is because it allows for the exchange of 158 routes previously exchanged via DVMRP, even though those routes would 159 not meet the existing unicast routing policy. It allows for 160 different policy in the interim. For example, routes may be 161 exchanged for BGP4+ multicast forwarding even though they would not 162 be permitted under existing unicast routing policy. BGP4+ also 163 provides for the possibility that even after full migration is 164 complete, a separate multicast routing policy can be applied. 166 The exchange architecture imposes no requirements on the IGP or the 167 multicast forwarding protocol or topology used internal to an AS. 169 5.2. Multicast Forwarding 171 The first requirement for the multicast forwarding protocol is that 172 it be able to use routes exchanged via BGP4+. In addition, there is 173 a requirement that the protocol only forward data upon explicit joins 174 from participating peers. For these reasons, PIM-SM was selected. 176 The use of PIM on a shared LAN has certain consequences. It is 177 necessary for all MIX participants to agree on certain configuration 178 conventions affecting PIM forwarding on multi-access LANs. In 179 particular, it is necessary to establish a standard protocol "metric 180 preference" (also known as "distance" or process "precedence") to be 181 used by all peers for the PIM Assert process, because the PIM Assert 182 process [PIM-SM] uses the "metric preference" [PIM-SM] as a mechanism 183 by which the multicast forwarder is chosen. If all parties are not 184 following the convention, there may be black holes, in which a route 185 appears to be valid, but traffic does not flow, or, there may be 186 multicast loops, which can have deleterious consequences. 188 For the MIX, a standard set of metric preferences are applied to the 189 BGP4+ routes as the convention for the PIM forwarding mechanism. 191 5.3. Active Sources 193 There are two current methods for distributing information about 194 active sources to participating AS's. The AS's may be dense-mode 195 regions, or, they may contain PIM-SM RP's. One method is to use 196 dense-mode to flood data packets to dense-mode regions and to 197 sparse-mode RPs co-located on the exchange. The second method is to 198 use a protocol that allows each AS to share information about the 199 sources contained within it without flooding data. 201 Recently, a new protocol, MSDP [MSDP] has been proposed that, when 202 combined with PIM-SM, allows independent AS's to share information 203 about distant sources and groups without flooding. Instead of 204 flooding all data, only information is flooded, and then, only 205 to systems, such as PIM-SM RP's, which require the information. MSDP 206 allows each AS to run its own sparse-mode region, independent of all 207 other sparse-mode regions. 209 MSDP peering is established by all MIX participants. Most MIX- 210 connected AS's are now running sparse-mode internally, or are 211 actively migrating. 213 5.4. Medium 215 A primary objective for a multicast exchange is to provide support 216 for native multicast among multiple peering partners. 218 There exist a number of unresolved issues regarding use of layer-2 219 switched media for multicast at interexchange points, and, until 220 these issues are resolved, running native multicast on such media can 221 be problematic. 223 Fortunately, BGP4+ permits unicast and multicast to be carried on 224 different media, permitting a multicast medium to be used 225 independently of the unicast medium if necessary. 227 A FDDI concentrator was selected for the Ames MIX to provide the 228 native multicast exchange medium. It was router-efficient, because it 229 permitted the medium to do the multicast packet replication, with a 230 single copy from a router being replicated to all neighbors. And 231 FDDI was considered operationally convenient by most of the 232 participants. Unicast traffic continues to be routed over the 233 existing unicast exchange media. 235 Any medium which supports native multicast at layer 2 can be used 236 efficiently. Other multicast exchanges are using switches with fast 237 and gigabit ethernet ports and the switch configured with multicast 238 as broadcast. Use of switching technology to handle layer 3 239 multicast requirements for inter-router communication is still 240 unresolved. At some exchanges, native multicast is handled over ATM 241 point-point VC's. 243 6. The NASA Ames Research Center Multicast-Friendly Internet Exchange 245 The Ames Multicast-friendly Internet eXchange, or MIX, began with the 246 first beta-test trials in March 1998, and became operational, 247 exchanging BGP4+ routes externally and using BGP4+ between multiple 248 AS's, in May 1998. NREN implemented BGP4+ and internal BGP4+ and 249 began trial external peerings in the same time frame, evolving from 250 the first trials, to full deployment by October. As of June 1999, 251 there were 10 AS's peering using PIM-SM, BGP4+, and MSDP to actively 252 exchange multicast on the MIX FDDI. One of the AS's, AS10888, acts 253 as a gateway between the DVMRP-based "Mbone" and the BGP4+ area. A 254 router within AS10888 has been located on the MIX by NREN. The 255 physical and logical topologies are as follows: 257 AS10888---R----"MBone" 258 | 259 MIX | multicast_exchange 260 ---------------- 261 / \ 262 / \ 263 bgp4+_peer---R R---bgp4+_peer 264 \ / 265 \ / 266 --------------- 267 FIX unicast_exchanges 269 7. Topology, Architecture, and Special Considerations 271 BGP4+ 273 -PIM Asserts and Metric preference 275 The PIM Assert mechanism requires that all routing protocols 276 "compete" to see which router is allowed for forward onto the shared 277 medium. To first order, the protocol metric preference is used to 278 determine the forwarder. All MIX peers must coordinate routing 279 protocol parameters so that one router does not inadvertantly win PIM 280 asserts over a neighbor which has a functional path. This requires 281 that BGP4+ routes have preference over other routes, such as BGP, 282 OSPF, and DVMRP. In particular, it was necessary to standardize 283 protocol metric preferences, and give BGP4+ routes the lowest, 284 preferred, dynamic routing protocol metric preferences. For this 285 reason, the standard set of BGP4+ metric preferences was chosen to be 286 less than any other dynamic unicast routing protocol metric 287 preferences. Any MIX routers which are using DVMRP must use a DVMRP 288 metric preference higher than the BGP4+ metric preferences, rather 289 than what many people have used previously as the DVMRP metric 290 preference, of 0. 292 -Default 294 One transitional requirement is the necessity to have routes to 295 "Mbone" sources, that is, sources within the global DVMRP routing 296 region. Currently, the mechanism used is to have a single router in 297 AS10888 on the MIX originate MBGP default to all external peers. 299 DVMRP routing 301 -DVMRP route redistribution 303 At present, all BGP4+ routes tagged with a particular community are 304 redistributed at the MIX into DVMRP within AS10888. This is to 305 provide DVMRP region users access to sources originating within AS's 306 that are being routed via BGP4+ exclusively. Unless a particular 307 community string is set, it is assumed that redistribution is not 308 desired. In the reverse direction, instead of sending DVMRP routes 309 into BGP4+, BGP4+ default is originated from the intermediary router. 311 In addition, local, stub-region DVMRP routes are redistributed into 312 BGP4+ internally by several of the peers. As long as the regions 313 remain stub regions, there is no danger, but, the possibility of a 314 backdoor into the Mbone presents an ever-present threat of loops 315 unless care is taken to redistribute only the routes which are known 316 to be owned within the AS. 318 8. Conclusions and Recommendations 320 -Provide support for native multicast 321 -Use BGP4+ as a method of exchanging routes for 322 inter-domain multicast 323 -Use PIM-SM with MSDP 324 -Concurrent use of BGP4+ and DVMRP for inter-domain 325 routing is not recommended. It is strongly 326 recommended to use BGP4+ exclusively for inter-domain 327 route exchange. 329 9. Security Considerations 331 There are no security considerations unique to the multicast 332 exchange. 334 10. References 336 [DVMRP] T. Pusateri, "Distance Vector Multicast Routing 337 Protocol", , 338 August 1998. 340 [BGP4+] T. Bates, R. Chandra, D. Katz, Y. Rekhter, 341 "Multiprotocol Extensions for BGP-4", RFC 2283, 342 February 1998. 344 [BGP4+2] T. Bates, R. Chandra, D. Katz, Y. Rekhter, 345 "Multiprotocol Extensions for BGP-4", Internet Draft, 346 , 347 August 1998. 349 [PIM-SM] D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. Deering, 350 M. Handley, V. Jacobson, C. Liu, P. Sharma, L. Wei, 351 "Protocol Independent Multicast-Sparse Mode (PIM-SM): 352 Protocol Specification", RFC 2362, June 1998. 354 [PIM-DM] S. Deering, D. Estrin, D. Farinacci, V. Jacobson, A. 355 Helmy, 356 D. Meyer, L. Wei, "Protocol Independent Multicast 357 Version 2 Dense Mode Specification", Internet Draft, 358 , November 1998. 360 [MSDP] D. Farinacci, Y. Rekhter, P. Lothberg, H. Kilmer, J. Hall, 361 "Multicast Source Discovery Protocol (MSDP)", 362 , June 1998. 364 11. Author's Address 366 Hugh LaMaster 367 Steve Shultz 368 NASA Ames Research Center 369 Mail Stop 233-21 370 Moffett Field, CA 94035-1000 371 email: hlamaster@arc.nasa.gov 372 shultz@arc.nasa.gov 374 David Meyer 375 John Meylor 376 Cisco Systems 377 San Jose, CA 378 email: dmm@cisco.com 379 jmeylor@cisco.com