Network Working Group. Category: Informational March 1994

Transcription

1 Netwrk Wrking Grup J. My Request fr Cmments: 1585 Prten, Inc. Categry: Infrmatinal March 1994 Status f this Mem MOSPF: Analysis and Experience This mem prvides infrmatin fr the Internet cmmunity. This mem des nt specify an Internet standard f any kind. Distributin f this mem is unlimited. Abstract This mem dcuments hw the MOSPF prtcl satisfies the requirements impsed n Internet ruting prtcls by "Internet Engineering Task Frce internet ruting prtcl standardizatin criteria" ([RFC 1264]). Please send cmments t mspf@gated.crnell.edu. 1. Summary f MOSPF features and algrithms MOSPF is an enhancement f OSPF V2, enabling the ruting f IP multicast datagrams. OSPF is a link-state (unicast) ruting prtcl, prviding a database describing the Autnmus System s tplgy. IP multicast is an extensin f LAN multicasting t a TCP/IP Internet. IP Multicast permits an IP hst t send a single datagram (called an IP multicast datagram) that will be delivered t multiple destinatins. IP multicast datagrams are identified as thse packets whse destinatins are class D IP addresses (i.e., addresses whse first byte lies in the range inclusive). Each class D address defines a multicast grup. The extensins required f an IP hst t participate in IP multicasting are specified in "Hst extensins fr IP multicasting" ([RFC 1112]). That dcument defines a prtcl, the Internet Grup Management Prtcl (IGMP), that enables hsts t dynamically jin and leave multicast grups. MOSPF ruters use the IGMP prtcl t mnitr multicast grup membership n lcal LANs thrugh the sending f IGMP Hst Membership Queries and the receptin f IGMP Hst Membership Reprts. A MOSPF ruter then distributes this grup lcatin infrmatin thrughut the ruting dmain by flding a new type f OSPF link state advertisement, the grup-membership-lsa (type 6). This in turn enables the MOSPF ruters t mst efficiently frward a multicast My [Page 1]

2 datagram t its multiple destinatins: each ruter calculates the path f the multicast datagram as a shrtest-path tree whse rt is the datagram surce, and whse terminal branches are LANs cntaining grup members. A separate tree is built fr each [surce netwrk, multicast destinatin] cmbinatin. T ease the cmputatinal demand n the ruters, these trees are built "n demand", i.e., the first time a datagram having a particular cmbinatin f surce netwrk and multicast destinatin is received. The results f these "n demand" tree calculatins are then cached fr later use by subsequent matching datagrams. MOSPF is meant t be used internal t a single Autnmus System. When supprting IP multicast ver the entire Internet, MOSPF wuld have t be used in cncert with an inter-as multicast ruting prtcl (smething like DVMRP wuld wrk). The MOSPF prtcl is based n the wrk f Steve Deering in [Deering]. The MOSPF specificatin is dcumented in [MOSPF] Characteristics f the multicast datagram s path As a multicast datagram is frwarded alng its shrtest-path tree, the datagram is delivered t each member f the destinatin multicast grup. In MOSPF, the frwarding f the multicast datagram has the fllwing prperties: The path taken by a multicast datagram depends bth n the datagram s surce and its multicast destinatin. Called surce/destinatin ruting, this is in cntrast t mst unicast datagram frwarding algrithms (like OSPF) that rute based slely n destinatin. The path taken between the datagram s surce and any particular destinatin grup member is the least cst path available. Cst is expressed in terms f the OSPF link-state metric. MOSPF takes advantage f any cmmnality f least cst paths t destinatin grup members. Hwever, when members f the multicast grup are spread ut ver multiple netwrks, the multicast datagram must at times be replicated. This replicatin is perfrmed as few times as pssible (at the tree branches), taking maximum advantage f cmmn path segments. Fr a given multicast datagram, all ruters calculate an identical shrtest-path tree. This is pssible since the shrtest-path tree is rted at the datagram surce, instead My [Page 2]

3 f being rted at the calculating ruter (as is dne in the unicast case). Tie-breakers have been defined t ensure that, when several equal-cst paths exist, all ruters agree n which single path t use. As a result, there is a single path between the datagram s surce and any particular destinatin grup member. This means that, unlike OSPF s treatment f regular (unicast) IP data traffic, there is n prvisin fr equal-cst multipath. While MOSPF ptimizes the path t any given grup member, it des nt necessarily ptimize the use f the internetwrk as a whle. T d s, instead f calculating surce-based shrtest-path trees, smething similar t a minimal spanning tree (cntaining nly the grup members) wuld need t be calculated. This type f minimal spanning tree is called a Steiner tree in the literature. Fr a cmparisn f shrtest-path tree ruting t ruting using Steiner trees, see [Deering2] and [Bharath-Kumar]. When frwarding a multicast datagram, MOSPF cnfrms t the link-layer encapsulatin standards fr IP multicast datagrams as specified in "Hst extensins fr IP multicasting" ([RFC 1112]), "Transmissin f IP datagrams ver the SMDS Service" ([RFC 1209]) and "Transmissin f IP and ARP ver FDDI Netwrks" ([RFC 1390]). In particular, fr ethernet and FDDI the explicit mapping between IP multicast addresses and data-link multicast addresses is used Miscellaneus features This sectin lists, in n particular rder, the ther miscellaneus features that the MOSPF prtcl supprts: MOSPF ruters can be mixed within an Autnmus System (and even within a single OSPF area) with nn-multicast OSPF ruters. When this is dne, all ruters will interperate in the ruting f unicasts. Unicast ruting will nt be affected by this mixing; all unicast paths will be the same as befre the intrductin f multicast. This mixing f multicast and nn-multicast ruters enables phased intrductin f a multicast capability int an internetwrk. Hwever, it shuld be nted that sme cnfiguratins f MOSPF and nn-mospf ruters may prduce unexpected failures in multicast ruting (see Sectin 6.1 f [MOSPF]). MOSPF des nt include the ability t tunnel multicast datagrams thrugh nn-multicast ruters. A tunneling capability has prved valuable when used by the DVMRP prtcl in the My [Page 3]

4 MBONE. Hwever, it is assumed that, since MOSPF is an intra-as prtcl, multicast can be turned n in enugh f the Autnmus System s ruters t achieve the required cnnectivity withut resrting t tunneling. The mre centralized cntrl that exists in mst Autnmus Systems, when cmpared t the Internet as a whle, shuld make this pssible. In additin t calculating a separate datagram path fr each [surce netwrk, multicast destinatin] cmbinatin, MOSPF can als vary the path based n IP Type f Service (TOS). As with OSPF unicast ruting, TOS-based multicast ruting is ptinal, and ruters supprting it can be freely mixed with thse that dn t. MOSPF supprts all netwrk types that are supprted by the base OSPF prtcl: bradcast netwrks, pint-t-pints netwrks and nn-bradcast multi-access (NBMA) netwrks. Nte hwever that IGMP is nt defined n NBMA netwrks, s while these netwrks can supprt the frwarding f multicast datagrams, they cannt supprt directly cnnected grup members. MOSPF supprts all Autnmus System cnfiguratins that are supprted by the base OSPF prtcl. In particular, an algrithm fr frwarding multicast datagrams between OSPF areas is included. Als, areas with cnfigured virtual links can be used fr transit multicast traffic. A way f frwarding multicast datagrams acrss Autnmus System bundaries has been defined. This means that a multicast datagram having an external surce can still be frwarded thrughut the Autnmus System. Facilities als exist fr frwarding lcally generated datagrams t Autnmus System exit pints, frm which they can be further distributed. The effectiveness f this supprt will depend upn the nature f the inter-as multicast ruting prtcl. The ne assumptin that has been made is that the inter-as multicast ruting prtcl will perate in an reverse path frwarding (RPF) fashin: namely, that multicast datagrams riginating frm an external surce will enter the Autnmus System at the same place that unicast datagrams destined fr that surce will exit. T deal with the fact that the external unicast and multicast tplgies will be different fr sme time t cme, a way t indicate that a rute is available fr multicast but nt unicast (r vice versa) has been defined. This fr example wuld allw a MOSPF system t use DVMRP as its inter-as multicast ruting prtcl, while using BGP as its inter-as unicast ruting prtcl. My [Page 4]

5 Fr thse physical netwrks that have been assigned multiple IP netwrk/subnet numbers, multicast ruting can be disabled n all but ne OSPF interface t the physical netwrk. This avids unwanted replicatin f multicast datagrams. Fr thse netwrks residing n Autnmus System bundaries, which may be running multiple multicast ruting prtcls (r multiple cpies f the same multicast ruting prtcl), MOSPF can be cnfigured t encapsulate multicast datagrams with unicast (rather than multicast) link-level destinatins. This als avids unwanted replicatin f multicast datagrams. MOSPF prvides an ptimizatin fr IP multicast s "expanding ring search" (smetimes called "TTL scping") prcedure. In an expanding ring search, an applicatin finds the nearest server by sending ut successive multicasts, each with a larger TTL. The first respnding server will then be the clsest (in terms f hps, but nt necessarily in terms f the OSPF metric). MOSPF minimizes the netwrk bandwidth cnsumed by an expanding ring search by refusing t frward multicast datagrams whse TTL is t small t ever reach a grup member. 2. Security architecture All MOSPF prtcl packet exchanges (excluding IGMP) are specified by the base OSPF prtcl, and as such are authenticated. Fr a discussin f OSPF s authenticatin mechanism, see Appendix D f [OSPF]. 3. MIB supprt Management supprt fr MOSPF has been added t the base OSPF V2 MIB [OSPF MIB]. These additins cnsist f the ability t read and write the cnfiguratin parameters specified in Sectin B f [MOSPF], tgether with the ability t dump the new grup-membership-lsas. 4. Implementatins There is currently ne MOSPF implementatin, written by Prten, Inc. It was released fr general use in April It is a full MOSPF implementatin, with the exceptin f TOS-based multicast ruting. It als des nt cntain an inter-as multicast ruting prtcl. The multicast applicatins included with the Prten MOSPF implementatin include: a multicast pinger, cnsle cmmands s that the ruter itself can jin and leave multicast grups (and s respnd t multicast pings), and the ability t send SNMP traps t a My [Page 5]

6 multicast address. Prten is als using IP multicast t supprt the tunneling f ther prtcls ver IP. Fr example, surce rute bridging is tunneled ver a MOSPF dmain, using ne IP multicast address fr explrer frames and mapping the segment/bridge fund in a specifically-ruted frame s RIF field t ther IP multicast addresses. This last applicatin has prved ppular, since it prvides a lightweight transprt that is resistant t rerdering. The Prten MOSPF implementatin is currently running in apprximately a dzen sites, each site cnsisting f ruters. Table 1 gives a cmparisn between the cde size f Prten s base OSPF implementatin and its MOSPF implementatin. Tw dimensins f lines f C bytes f bject cde OSPF base 11,693 63,160 MOSPF 15,247 81,956 Table 1: Cmparisn f OSPF and MOSPF cde sizes size are indicated: lines f C (cmments and blanks included), and bytes f bject cde. In bth cases, the multicast extensins t OSPF have engendered a 30% size increase. Nte that in these sizes, the cde used t cnfigure and mnitr the implementatin has been included. Als, in the MOSPF cde size figure, the IGMP implementatin has been included. 5. Testing Figure 1 shws the tplgy that was used fr the initial debugging f Prten s MOSPF implementatin. It cnsists f seven MOSPF ruters, intercnnected by ethernets, tken rings, FDDIs and serial lines. The applicatins used t test the ruting were multicast ping and the sending f traps t a multicast address (the bx labeled "NAZ" was a netwrk analyzer that was ccasinally sending IGMP Hst Membership Reprts and then cntinuusly receiving multicast SNMP traps). The "vat" applicatin was als used n wrkstatins (withut running the DVMRP "mruted" daemn; see "Distance Vectr Multicast Ruting Prtcl", [RFC 1075]) which were multicasting packet vice acrss the MOSPF dmain. My [Page 6]

7 The MOSPF features tested in this setup were: Re-ruting in respnse t tplgy changes. Path verificatin after altering csts. Ruting multicast datagrams between areas. Ruting multicast datagrams t and frm external addresses. The varius tiebreakers emplyed when cnstructing datagram shrtest-path trees. MOSPF ver nn-bradcast multi-access netwrks. Interperability f MOSPF and nn-multicast OSPF ruters RT RT RT2 NAZ RT RT RT RT Figure 1: Initial MOSPF test setup My [Page 7]

8 Due t the cmmercial tunneling applicatins develped by Prten that use IP multicast, MOSPF has been deplyed in a number f peratinal but nn-internet-cnnected sites. MOSPF has been als deplyed in sme Internet-cnnected sites (e.g., OARnet) fr testing purpses. The desire f these sites is t use MOSPF t attach t the "mbne". Hwever, an implementatin f bth MOSPF and DVMRP in the same bx is needed; withut this ne way cmmunicatin has been achieved (srt f like lecture mde in vat) by cnfiguring multicast static rutes in the MOSPF implementatin. The prblem is that there is n current way t inject the MOSPF surce infrmatin int DVMRP. The MOSPF features that have nt yet been tested are: The interactin between MOSPF and virtual links. Interactin between MOSPF and ther multicast ruting prtcls (e.g., DVMRP). TOS-based ruting in MOSPF. 6. A brief analysis f MOSPF scaling MOSPF uses the Dijkstra algrithm t calculate the path f a multicast datagram thrugh any given OSPF area. This calculatin encmpasses all the transit ndes (ruters and netwrks) in the area; its cst scales as O(N*lg(N)) where N is the number f transit ndes (same as the cst f the OSPF unicast intra-area ruting calculatin). This is the cst f a single path calculatin; hwever, MOSPF calculates a separate path fr each [surce netwrk, multicast destinatin, TOS] tuple. This is ptentially a lt f Dijkstra calculatins. MOSPF prpses t deal with this calculatin burden by calculating datagram paths in an "n demand" fashin. That is, the path is calculated nly when receiving the first datagram in a stream. After the calculatin, the results are cached fr use by later matching datagrams. This n demand calculatin alleviates the cst f the ruting calculatins in tw ways: 1) It spreads the ruting calculatins ut ver time and 2) the ruter des fewer calculatins, since it des nt even calculate the paths f datagrams whse path will nt even tuch the ruter. Cache entries need never be timed ut, althugh they are remved n tplgical changes. If an implementatin chses t limit the amunt f memry cnsumed by the cache, prbably by remving selected entries, care must be taken t ensure that cache thrashing des nt ccur. My [Page 8]

9 The effectiveness f this "n demand" calculatin will need t be prven ver time, as multicast usage and traffic patterns becme mre evident. As a simple example, suppse an OSPF area cnsists f 200 ruters. Suppse each ruter represents a site, and each site is participating simultaneusly with three ther lcal sites (inside the area) in a vide cnference. This gives 200/4 = 50 grups, and 200 separate datagram trees. Assuming each datagram tree ges thrugh every ruter (which prbably wn t be true), each ruter will be ding 200 Dijkstras initially (and n internal tplgy changes). The time t run a 200 nde Dijkstra n a 10 mips prcessr was estimated t be 15 millisecnds in "OSPF prtcl analysis" ([RFC 1245]). S if all 200 Dijkstras need t be dne at nce, it will take 3 secnds ttal n a 10 mips prcessr. In cntrast, assuming each vide stream is 64Kb/sec, the ruters will cnstantly frward 12Mb/sec f applicatin data (the cst f this sn dwarfing the cst f the Dijkstras). In this example there are als 200 grup-membership-lsas in the area; since each grup membership-lsa is arund 64 bytes, this adds 64*200 = 12K bytes t the OSPF link state database. Other things t keep in mind when evaluating the cst f MOSPF s ruting calculatin are: Assuming that the guidelines f "OSPF prtcl analysis" ([RFC 1245]) are fllwed and areas are limited t 200 ndes, the cst f the Dijkstra will nt grw unbunded, but will instead be capped at the Dijkstra fr 200 ndes. One need then wrry abut the number f Dijkstras, which is determined by the number f [datagram surce, multicast destinatin] cmbinatins. A datagram whse destinatin has n grup members in the dmain can still be frwarded thrugh the MOSPF system. Hwever, the Dijkstra calculatin here depends nly n the [datagram surce, TOS], since the datagram will be frwarded alng t "wild-card receivers" nly. Since the number f grup members in a 200 ruter area is prbably als bunded, the pssibility f unbunded calculatin grwth lies in the number f pssible datagram surces. (Hwever, it shuld be nted that sme future multicast applicatins, such as distributed cmputing, may generate a large number f shrt-lived multicast grups). By cllapsing ruting infrmatin befre imprting it int the area/as, the number f surces can be reduced dramatically. In particular, if the AS relies n a default external rute, mst external surces will be cvered by a single Dijkstra calculatin (the ne using as the surce). My [Page 9]

10 One ther factr t be cnsidered in MOSPF scaling is hw ften cache entries need t be recalculated, as a result f a netwrk tplgy change. The rules fr MOSPF cache maintenance are explained in Sectin 13 f [MOSPF]. Nte that the further away the tplgy change happens frm the calculating ruter, the fewer cache entries need t be recalculated. Fr example, if an external rute changes, many fewer cache entries need t be purged as cmpared t a change in a MOSPF dmain s internal link. Fr scaling purpses, this is exactly the desired behavir. Nte that "OSPF prtcl analysis" ([RFC 1245]) bears this ut when it shws that changes in external rutes (n the rder f nce a minute fr the netwrks surveyed) are much mre frequent than internal changes (between 15 and 50 minutes fr the netwrks surveyed). 7. Knwn difficulties The fllwing are knwn difficulties with the MOSPF prtcl: When a MOSPF ruter itself cntains multicast applicatins, the chice f its applicatin datagrams surce addresses shuld be made with care. Due t OSPF s representatin f serial lines, using a serial line interface address as surce can lead t excess data traffic n the serial line. In fact, using any interface address as surce can lead t excess traffic, wing t MOSPF s decisin t always multicast the packet nt the surce netwrk as part f the frwarding prcess (see Sectin 11.3 f [MOSPF]). Hwever, ptimal behavir can be achieved by assigning the ruter an interface-independent address, and using this as the datagram surce. This cncern des nt apply t regular IP hsts (i.e., thse that are nt MOSPF ruters). It is necessary t ensure, when mixing MOSPF and nn-multicast ruters n a LAN, that a MOSPF ruter becmes Designated Ruter. Otherwise multicast datagrams will nt be frwarded n the LAN, nr will grup membership be mnitred n the LAN, nr will the grup-membership-lsas be flded ver the LAN. This can be an peratinal nuisance, since OSPF s Designated Ruter electin algrithm is designed t discurage Designated Ruter transitins, rather than t guarantee that certain ruters becme Designated Ruter. Hwever, assigning a DR Pririty f 0 t all nn-multicast ruters will always guarantee that a MOSPF ruter is selected as Designated Ruter. My [Page 10]

11 8. Future wrk In the future, it is expected that the fllwing wrk will be dne n the MOSPF prtcl: Mre analysis f multicast traffic patterns needs t be dne, in rder t see whether the MOSPF ruting calculatins will pse an undue prcessing burden n multicast ruters. If necessary, further ways t ease this burden may need t be defined. One suggestin that has been made is t revert t reverse path frwarding when the ruter is unable t calculate the detailed MOSPF frwarding cache entries. Experience needs t be gained with the interactins between multiple multicast ruting algrithms (e.g., MOSPF and DVMRP). Additinal MIB supprt fr the retrieval f frwarding cache entries, alng the lines f the "IP frwarding table MIB" ([RFC 1354]), wuld be useful. My [Page 11]

12 9. References [Bharath-Kumar] Bharath-Kumar, K., and J. Jaffe, "Ruting t multiple destinatins in Cmputer Netwrks", IEEE Transactins n Cmmunicatins, COM-31[3], March [Deering] [Deering2] [OSPF] [OSPF MIB] Deering, S., "Multicast Ruting in Internetwrks and Extended LANs", SIGCOMM Summer 1988 Prceedings, August Deering, S., "Multicast Ruting in a Datagram Internetwrk", Stanfrd Technical Reprt STAN-CS , Department f Cmputer Science, Stanfrd University, December My, J., "OSPF Versin 2", RFC 1583, Prten, Inc., March Baker F., and R. Cltun, "OSPF Versin 2 Management Infrmatin Base", RFC 1253, ACC, Cmputer Science Center, August [MOSPF] My, J., "Multicast Extensins t OSPF", RFC 1584, Prten, Inc., March [RFC 1075] [RFC 1112] [RFC 1209] [RFC 1245] [RFC 1246] [RFC 1264] Waitzman, D., Partridge, C. and S. Deering, "Distance Vectr Multicast Ruting Prtcl", RFC 1075, BBN STC, Stanfrd University, Nvember Deering, S., "Hst Extensins fr IP Multicasting", Stanfrd University, RFC 1112, May Piscitell, D., and J. Lawrence, "Transmissin f IP Datagrams ver the SMDS Service", RFC 1209, Bell Cmmunicatins Research, March My, J., Editr, "OSPF Prtcl Analysis", RFC 1245, Prten, Inc., July My, J., Editr, "Experience with the OSPF Prtcl", RFC 1245, Prten, Inc., July Hinden, R., "Internet Ruting Prtcl Standardizatin Criteria", RFC 1264, BBN, Octber My [Page 12]

13 [RFC 1390] Katz, D., "Transmissin f IP and ARP ver FDDI Netwrks", RFC 1390, cisc Systems, Inc., January [RFC 1354] Baker, F., "IP Frwarding Table MIB", RFC 1354, ACC, July Security Cnsideratins Security issues are nt discussed in this mem, th see Sectin 2. Authr s Address Jhn My Prten, Inc. 9 Technlgy Drive Westbrugh, MA Phne: (508) jmy@prten.cm My [Page 13]