RFC 1585

MOSPF: Analysis and Experience

📅 published March 1994, from ietf

RFC 1585: MOSPF: Analysis and Experience 🦋

Okay bestie, this is RFC 1585, and it's giving serious routing lore 💅 It was written by J. Moy of Proteon, Inc. and published in March 1994 under the Network Working Group. The category is Informational, so it's sharing info, not a standard 🌸 The header doesn't list anything it obsoletes or updates ✨

Status of this Memo

This memo gives info to the Internet community 🌈 It does not specify an Internet standard of any kind, and distribution of it is unlimited 💖

Abstract

Here's the tea: this memo shows how MOSPF meets the requirements that "Internet Engineering Task Force internet routing protocol standardization criteria" ([RFC 1264]) puts on Internet routing protocols 🧚 Send comments to mospf@gated.cornell.edu 💌

1. Summary of MOSPF features and algorithms ✨

MOSPF is an enhancement of OSPF V2 that lets IP multicast datagrams get routed 🦋 OSPF is a link-state (unicast) routing protocol that keeps a database describing the Autonomous System's topology. IP multicast is an extension of LAN multicasting to a TCP/IP Internet. With it, an IP host can send one single datagram (called an IP multicast datagram) that gets delivered to multiple destinations. IP multicast datagrams are the packets whose destinations are class D IP addresses, meaning addresses whose first byte lies in the range 224-239 inclusive. Each class D address defines a multicast group 🎀

The extensions an IP host needs to take part in IP multicasting are specified in "Host extensions for IP multicasting" ([RFC 1112]). That document defines the Internet Group Management Protocol (IGMP), which lets hosts dynamically join and leave multicast groups 🙈

MOSPF routers use IGMP to keep an eye on multicast group membership on local LANs, by sending IGMP Host Membership Queries and receiving IGMP Host Membership Reports 👀 A MOSPF router then spreads this group location info across the whole routing domain by flooding a new type of OSPF link state advertisement, the group-membership-LSA (type 6). This is how MOSPF routers forward a multicast datagram to its multiple destinations most efficiently 🔥 Each router calculates the path of the datagram as a shortest-path tree whose root is the datagram source, and whose terminal branches are LANs containing group members.

A separate tree is built for each [source network, multicast destination] combination. To ease the computational demand on routers, these trees are built "on demand", i.e., the first time a datagram with a particular combination of source network and multicast destination is received. The results of these "on demand" tree calculations are then cached for later use by subsequent matching datagrams 💜

MOSPF is meant to be used inside a single Autonomous System. To support IP multicast over the entire Internet, MOSPF would have to be used together with an inter-AS multicast routing protocol (something like DVMRP would work) 🌍

The MOSPF protocol is based on the work of Steve Deering in [Deering]. The MOSPF specification is documented in [MOSPF] 📚

1.1. Characteristics of the multicast datagram's path

As a multicast datagram is forwarded along its shortest-path tree, it gets delivered to each member of the destination multicast group 🍓 In MOSPF, that forwarding has these properties:

  • The path taken depends on both the datagram's source and its multicast destination. This is called source/destination routing, and it's different from most unicast forwarding algorithms (like OSPF), which route based solely on destination 💅
  • The path between the datagram's source and any particular destination group member is the least cost path available. Cost is expressed in terms of the OSPF link-state metric ✨
  • MOSPF takes advantage of any commonality of least cost paths to destination group members. However, when members of the multicast group are spread out over multiple networks, the multicast datagram must at times be replicated. This replication is performed as few times as possible (at the tree branches), taking maximum advantage of common path segments 🦋
  • For a given multicast datagram, all routers calculate an identical shortest-path tree. This is possible because the tree is rooted at the datagram source, instead of at the calculating router (as is done in the unicast case). Tie-breakers have been defined to ensure that, when several equal-cost paths exist, all routers agree on which single path to use. As a result, there is a single path between the datagram's source and any particular destination group member. This means that, unlike OSPF's treatment of regular (unicast) IP data traffic, there is no provision for equal-cost multipath 🫶
  • While MOSPF optimizes the path to any given group member, it does not necessarily optimize the use of the internetwork as a whole. To do that, instead of calculating source-based shortest-path trees, something similar to a minimal spanning tree (containing only the group members) would need to be calculated. This type of minimal spanning tree is called a Steiner tree in the literature. For a comparison of shortest-path tree routing to routing using Steiner trees, see [Deering2] and [Bharath-Kumar] 🧠
  • When forwarding a multicast datagram, MOSPF conforms to the link-layer encapsulation standards for IP multicast datagrams as specified in "Host extensions for IP multicasting" ([RFC 1112]), "Transmission of IP datagrams over the SMDS Service" ([RFC 1209]) and "Transmission of IP and ARP over FDDI Networks" ([RFC 1390]). In particular, for ethernet and FDDI the explicit mapping between IP multicast addresses and data-link multicast addresses is used 🎀

1.2. Miscellaneous features

This section lists, in no particular order, the other miscellaneous features that MOSPF supports 🌸

  • MOSPF routers can be mixed within an Autonomous System (and even within a single OSPF area) with non-multicast OSPF routers. When this is done, all routers interoperate in the routing of unicasts. Unicast routing is not affected by this mixing, so all unicast paths are the same as before multicast was introduced. This mixing of multicast and non-multicast routers enables a phased introduction of multicast capability into an internetwork. However, it should be noted that some configurations of MOSPF and non-MOSPF routers may produce unexpected failures in multicast routing (see Section 6.1 of [MOSPF]) 🙃
  • MOSPF does not include the ability to tunnel multicast datagrams through non-multicast routers. Tunneling has proved valuable when used by the DVMRP protocol in the MBONE. However, it is assumed that, since MOSPF is an intra-AS protocol, multicast can be turned on in enough of the Autonomous System's routers to achieve the required connectivity without resorting to tunneling. The more centralized control that exists in most Autonomous Systems, compared with the Internet as a whole, should make this possible 🧚
  • In addition to calculating a separate datagram path for each [source network, multicast destination] combination, MOSPF can also vary the path based on IP Type of Service (TOS). As with OSPF unicast routing, TOS-based multicast routing is optional, and routers that support it can be freely mixed with those that don't 🦋
  • MOSPF supports all network types that are supported by the base OSPF protocol: broadcast networks, point-to-points networks and non-broadcast multi-access (NBMA) networks. Note however that IGMP is not defined on NBMA networks, so while these networks can support the forwarding of multicast datagrams, they cannot support directly connected group members ⚠️
  • MOSPF supports all Autonomous System configurations that are supported by the base OSPF protocol. In particular, an algorithm for forwarding multicast datagrams between OSPF areas is included. Also, areas with configured virtual links can be used for transit multicast traffic 👑
  • A way of forwarding multicast datagrams across Autonomous System boundaries has been defined. This means that a multicast datagram having an external source can still be forwarded throughout the Autonomous System. Facilities also exist for forwarding locally generated datagrams to Autonomous System exit points, from which they can be further distributed. The effectiveness of this support depends on the nature of the inter-AS multicast routing protocol. The one assumption made is that the inter-AS multicast routing protocol operates in a reverse path forwarding (RPF) fashion: namely, that multicast datagrams originating from an external source enter the Autonomous System at the same place that unicast datagrams destined for that source exit 🌈
  • To deal with the fact that external unicast and multicast topologies will be different for some time to come, a way to indicate that a route is available for multicast but not unicast (or vice versa) has been defined. For example, this would allow a MOSPF system to use DVMRP as its inter-AS multicast routing protocol, while using BGP as its inter-AS unicast routing protocol 🍓
  • For physical networks that have been assigned multiple IP network/subnet numbers, multicast routing can be disabled on all but one OSPF interface to the physical network. This avoids unwanted replication of multicast datagrams 💜
  • For networks residing on Autonomous System boundaries, which may be running multiple multicast routing protocols (or multiple copies of the same multicast routing protocol), MOSPF can be configured to encapsulate multicast datagrams with unicast (rather than multicast) link-level destinations. This also avoids unwanted replication of multicast datagrams 🌸
  • MOSPF provides an optimization for IP multicast's "expanding ring search" (sometimes called "TTL scoping") procedure. In an expanding ring search, an application finds the nearest server by sending out successive multicasts, each with a larger TTL. The first responding server will then be the closest (in terms of hops, but not necessarily in terms of the OSPF metric). MOSPF minimizes the network bandwidth consumed by an expanding ring search by refusing to forward multicast datagrams whose TTL is too small to ever reach a group member 🧚‍♀️

2. Security architecture 🔐

All MOSPF protocol packet exchanges (excluding IGMP) are specified by the base OSPF protocol, and as such they are authenticated 😭 For a discussion of OSPF's authentication mechanism, see Appendix D of [OSPF].

3. MIB support 🎀

okay so management support for MOSPF got added to the base OSPF V2 MIB [OSPF MIB] 💖 bestie, that means you can read and write the configuration parameters from Section B of [MOSPF], and you can also dump the new group-membership-LSAs. full admin main character energy 👑

4. Implementations 💅

there is currently exactly ONE MOSPF implementation, and it's by Proteon, Inc. 🧚 it got released for general use in April 1992 and it's a full MOSPF implementation, except it does NOT do TOS-based multicast routing, and it doesn't have an inter-AS multicast routing protocol either. so not perfect, but literally iconic for its time 🌸

the multicast apps that come with Proteon's MOSPF are giving a whole buffet 🍓 there's a multicast pinger, console commands so the router itself can join and leave multicast groups (and then respond to multicast pings, which is so cute), and the ability to send SNMP traps to a multicast address. and get this, Proteon is also using IP multicast to tunnel other protocols over IP ✨ for example, source route bridging gets tunneled over a MOSPF domain. it uses one IP multicast address for explorer frames, and then it maps the segment/bridge found in a specifically-routed frame's RIF field to other IP multicast addresses. ngl this one is the most popular app of all because it's a lightweight transport that is resistant to reordering 🫶

the Proteon MOSPF implementation is currently running in approximately a dozen sites, and each site has 10-20 routers 🦋

the code size comparison is up next (Table 1 is the tea ☕). it compares Proteon's base OSPF implementation with its MOSPF implementation, measured two ways: lines of C (comments and blanks included), and bytes of 68020 object code. in both cases the multicast extensions to OSPF made things about 30% bigger 📈

                      lines of C   bytes of 68020 object code
          ___________________________________________________
          OSPF base   11,693       63,160
          MOSPF       15,247       81,956

            Table 1: Comparison of OSPF and MOSPF code sizes

just so you know, these sizes include the code used to configure and monitor the implementation 🙈 and the MOSPF figure also includes the IGMP implementation.

5. Testing 🧪

Figure 1 shows the topology that was used for the initial debugging of Proteon's MOSPF implementation 🌈 it's seven MOSPF routers hooked up with ethernets, token rings, FDDIs, and serial lines. the apps used to test routing were multicast ping and sending traps to a multicast address. the box labeled "NAZ" was a network analyzer that occasionally sent IGMP Host Membership Reports and then kept receiving multicast SNMP traps 👀 the "vat" application was also run on workstations (without running the DVMRP "mrouted" daemon; see "Distance Vector Multicast Routing Protocol", [RFC 1075]) and those workstations were multicasting packet voice across the MOSPF domain 🎤

                                              +---+
              +-------------------------------|RT1|
              |                               +---+
              |             +---------+         |
              |                  |              |
              |  +---+         +---+    +---+   |
              |  |RT5|---------|RT2|    |NAZ|   |
              |  +---+    +----+---+    +---+   |
              |           |      |        |     |
              |           |   +------------------------+
              |           |                         |      +
              |           |                         |      |
              |           |                         |      |  +---+
              |   +------------+      +             |      |--|RT7|
              |            |          |             |      |  +---+
              |          +---+        |           +---+    |
              |          |RT4|--------|-----------|RT3|----|
              |          +---+        |           +---+    |
              |                       |                    |
              |               +       +                    |
              |               |           +---+            |
              +---------------|-----------|RT6|------------|
                              |           +---+            |
                              +                            +

                  Figure 1: Initial MOSPF test setup

these MOSPF features got tested in this setup, and they passed the vibe check ✨

  • Re-routing in response to topology changes. 🔁
  • Path verification after altering costs.
  • Routing multicast datagrams between areas.
  • Routing multicast datagrams to and from external addresses.
  • The various tiebreakers employed when constructing datagram shortest-path trees.
  • MOSPF over non-broadcast multi-access networks.
  • Interoperability of MOSPF and non-multicast OSPF routers.

now the deployment tea ☕ because of the commercial tunneling apps Proteon built on IP multicast, MOSPF has been deployed in a bunch of operational sites that are NOT connected to the Internet 🏠 MOSPF has also been deployed in some Internet-connected sites (e.g., OARnet) for testing purposes. those sites want to use MOSPF to attach to the "mbone" 🌐 but they need an implementation of both MOSPF and DVMRP in the same box, and without that, one-way communication has been achieved (sort of like lecture mode in vat) by configuring multicast static routes in the MOSPF implementation. the problem is there's currently no way to inject the MOSPF source information into DVMRP 😭

these MOSPF features haven't been tested yet, so stay tuned 🦋

  • The interaction between MOSPF and virtual links.
  • Interaction between MOSPF and other multicast routing protocols (e.g., DVMRP).
  • TOS-based routing in MOSPF.

6. A brief analysis of MOSPF scaling 📊

okay bestie, let's talk scaling 🤓 MOSPF uses the Dijkstra algorithm to calculate the path of a multicast datagram through any given OSPF area. this calculation covers all the transit nodes (routers and networks) in the area, and its cost scales as O(N*log(N)) where N is the number of transit nodes (same cost as the OSPF unicast intra-area routing calculation). that's the cost of ONE path calculation, but MOSPF calculates a separate path for each [source network, multicast destination, TOS] tuple. so yeah, that's potentially a LOT of Dijkstra calculations 💀

MOSPF handles this calculation burden by calculating datagram paths "on demand" 🧚 the path only gets calculated when the first datagram in a stream comes in. after that, the results get cached for later matching datagrams. this on demand approach helps the cost in two ways: 1) it spreads the routing calculations out over time, and 2) the router does fewer calculations, since it doesn't even calculate paths for datagrams whose path won't touch the router. iconic efficiency 💖

cache entries never need to time out 🌸 but they do get removed on topological changes. if an implementation decides to limit how much memory the cache eats (probably by removing selected entries), it has to be careful to make sure cache thrashing doesn't happen 🙈

the effectiveness of this "on demand" calculation will need to be proven over time, as multicast usage and traffic patterns become more evident 🔮

here's a simple example, so picture this: an OSPF area has 200 routers, and each router is a site. each site is simultaneously participating with three other local sites (inside the area) in a video conference. that gives 200/4 = 50 groups, and 200 separate datagram trees. assuming each datagram tree goes through every router (which probably won't be true), each router will be doing 200 Dijkstras initially (and again on internal topology changes). the time to run a 200 node Dijkstra on a 10 mips processor was estimated to be 15 milliseconds in "OSPF protocol analysis" ([RFC 1245]). so if all 200 Dijkstras need to happen at once, that's 3 seconds total on a 10 mips processor ⏱️ meanwhile, if each video stream is 64Kb/sec, the routers will constantly forward 12Mb/sec of application data. the cost of forwarding that data soon dwarfs the cost of the Dijkstras 🔥

in this example there are also 200 group-membership-LSAs in the area. each group-membership-LSA is around 64 bytes, so that adds 64*200 = 12K bytes to the OSPF link state database 🗃️

some other things to keep in mind when you're evaluating the cost of MOSPF's routing calculation:

  • Assuming the guidelines of "OSPF protocol analysis" ([RFC 1245]) are followed and areas are limited to 200 nodes, the cost of the Dijkstra won't grow unbounded. it gets capped at the Dijkstra for 200 nodes. so the thing to worry about is the number of Dijkstras, which is determined by the number of [datagram source, multicast destination] combinations. 🧮
  • A datagram whose destination has no group members in the domain can still be forwarded through the MOSPF system. the Dijkstra calculation here depends only on the [datagram source, TOS], since the datagram gets forwarded along to "wild-card receivers" only. since the number of group members in a 200 router area is probably also bounded, the possibility of unbounded calculation growth lives in the number of possible datagram sources. (however, it should be noted that some future multicast apps, like distributed computing, may generate a large number of short-lived multicast groups 👀)
  • if you collapse routing information before importing it into the area/AS, the number of sources can be reduced dramatically 📉 in particular, if the AS relies on a default external route, most external sources get covered by a single Dijkstra calculation (the one using 0.0.0.0 as the source).

one more factor for MOSPF scaling is how often cache entries need to be recalculated because of a network topology change 🔄 the rules for MOSPF cache maintenance are explained in Section 13 of [MOSPF]. the further away the topology change happens from the calculating router, the fewer cache entries need to be recalculated. for example, if an external route changes, way fewer cache entries need to be purged compared to a change in a MOSPF domain's internal link. for scaling purposes, that's exactly the behavior you want 💅 "OSPF protocol analysis" ([RFC 1245]) backs this up: it shows that changes in external routes (on the order of once a minute for the networks surveyed) are much more frequent than internal changes (between 15 and 50 minutes for the networks surveyed) ✨

7. Known difficulties ✨

okay so these are the known difficulties with MOSPF 😭 the stuff that can still trip people up, bestie 💅

  • When a MOSPF router itself has multicast applications running on it, the choice of its application datagrams' source addresses should be made with care 🧐. Because of how OSPF represents serial lines, using a serial line interface address as source can lead to excess data traffic on the serial line. Honestly, using any interface address as source can lead to excess traffic, since MOSPF always decides to multicast the packet onto the source network as part of the forwarding process (see Section 11.3 of [MOSPF]) 🙈. BUT optimal behavior can be achieved by giving the router an interface-independent address and using that as the datagram source 💖.

This concern does not apply to regular IP hosts (i.e., those that are not MOSPF routers) 🙅.

  • It is necessary to ensure, when mixing MOSPF and non-multicast routers on a LAN, that a MOSPF router becomes Designated Router 👑. Otherwise multicast datagrams will not be forwarded on the LAN, nor will group membership be monitored on the LAN, nor will the group-membership-LSAs be flooded over the LAN 💀. This can be an operational nuisance, since OSPF's Designated Router election algorithm is designed to discourage Designated Router transitions, rather than to guarantee that certain routers become Designated Router 😤. However, assigning a DR Priority of 0 to all non-multicast routers will always guarantee that a MOSPF router is selected as Designated Router ✨.

8. Future work

so here's what's expected to happen with MOSPF down the road 🔮

  • More analysis of multicast traffic patterns needs to be done, in order to see whether the MOSPF routing calculations will pose an undue processing burden on multicast routers 📊. If necessary, further ways to ease this burden may need to be defined. One suggestion that has been made is to revert to reverse path forwarding when the router is unable to calculate the detailed MOSPF forwarding cache entries 🤔.
  • Experience needs to be gained with the interactions between multiple multicast routing algorithms (e.g., MOSPF and DVMRP) 🧪.
  • Additional MIB support for the retrieval of forwarding cache entries, along the lines of the "IP forwarding table MIB" ([RFC 1354]), would be useful 🍓.

9. References 📚

[Bharath-Kumar] Bharath-Kumar, K., and J. Jaffe, "Routing to
                multiple destinations in Computer Networks", IEEE
                Transactions on Communications, COM-31[3], March
                1983.

[Deering]       Deering, S., "Multicast Routing in Internetworks
                and Extended LANs", SIGCOMM Summer 1988
                Proceedings, August 1988.

[Deering2]      Deering, S., "Multicast Routing in a Datagram
                Internetwork", Stanford Technical Report
                STAN-CS-92-1415, Department of Computer Science,
                Stanford University, December 1991.

[OSPF]          Moy, J., "OSPF Version 2", RFC 1583, Proteon,
                Inc., March 1994.

[OSPF MIB]      Baker F., and R. Coltun, "OSPF Version 2 Management
                Information Base", RFC 1253, ACC, Computer Science
                Center, August 1991.

[MOSPF]         Moy, J., "Multicast Extensions to OSPF", RFC 1584,
                Proteon, Inc., March 1994.

[RFC 1075]      Waitzman, D., Partridge, C. and S. Deering,
                "Distance Vector Multicast Routing Protocol", RFC
                1075, BBN STC, Stanford University, November 1988.

[RFC 1112]      Deering, S., "Host Extensions for IP Multicasting",
                Stanford University, RFC 1112, May 1988.

[RFC 1209]      Piscitello, D., and J. Lawrence, "Transmission of IP
                Datagrams over the SMDS Service", RFC 1209, Bell
                Communications Research, March 1991.

[RFC 1245]      Moy, J., Editor, "OSPF Protocol Analysis", RFC
                1245, Proteon, Inc., July 1991.

[RFC 1246]      Moy, J., Editor, "Experience with the OSPF
                Protocol", RFC 1245, Proteon, Inc., July 1991.

[RFC 1264]      Hinden, R., "Internet Routing Protocol
                Standardization Criteria", RFC 1264, BBN, October
                1991.

[RFC 1390]      Katz, D., "Transmission of IP and ARP over FDDI
                Networks", RFC 1390, cisco Systems, Inc., January
                1993.

[RFC 1354]      Baker, F., "IP Forwarding Table MIB", RFC 1354,
                ACC, July 1992.

Security Considerations 🔐

okay so security isn't discussed in this memo, tho see Section 2 🥺🔐

Author's Address 🦋

John Moy
Proteon, Inc.
9 Technology Drive
Westborough, MA 01581

Phone: (508) 898-2800
EMail: jmoy@proteon.com
📦 where this page comes from