As per Relevance of the word experience, we have this rfc below:
Network Working Group J.
Request for Comments: 1585 Proteon, Inc
Category: Informational March 1994
MOSPF: Analysis and
Status of this
This memo provides information for the Internet community. This
does not specify an Internet standard of any kind. Distribution
this memo is unlimited
This memo documents how the MOSPF protocol satisfies the
imposed on Internet routing protocols by "Internet Engineering
Force internet routing protocol standardization criteria" ([
1264]).
Please send comments to mospf@gated.cornell.edu
1. Summary of MOSPF features and
MOSPF is an enhancement of OSPF V2, enabling the routing of
multicast datagrams. OSPF is a link-state (unicast)
protocol, providing a database describing the Autonomous System'
topology. IP multicast is an extension of LAN multicasting to
TCP/IP Internet. IP Multicast permits an IP host to send a
datagram (called an IP multicast datagram) that will be delivered
multiple destinations. IP multicast datagrams are identified
those packets whose destinations are class D IP addresses (i.e.,
addresses whose first byte lies in the range 224-239 inclusive).
Each class D address defines a multicast group
The extensions required of an IP host to participate in
multicasting are specified in "Host extensions for IP multicasting
([RFC 1112]). That document defines a protocol, the Internet
Management Protocol (IGMP), that enables hosts to dynamically
and leave multicast groups
MOSPF routers use the IGMP protocol to monitor multicast
membership on local LANs through the sending of IGMP Host
Queries and the reception of IGMP Host Membership Reports. A
router then distributes this group location information
the routing domain by flooding a new type of OSPF link
advertisement, the group-membership-LSA (type 6). This in
enables the MOSPF routers to most efficiently forward a
Moy [Page 1]
RFC 1585 MOSPF: Analysis and Experience March 1994
datagram to its multiple destinations: each router calculates
path of the multicast datagram as a shortest-path tree whose root
the datagram source, and whose terminal branches are LANs
group members
A separate tree is built for each [source network,
destination] combination. To ease the computational demand on
routers, these trees are built "on demand", i.e., the first time
datagram having a particular combination of source network
multicast destination is received. The results of these "on demand
tree calculations are then cached for later use by
matching datagrams
MOSPF is meant to be used internal to a single Autonomous System
When supporting IP multicast over the entire Internet, MOSPF
have to be used in concert with an inter-AS multicast
protocol (something like DVMRP would work).
The MOSPF protocol is based on the work of Steve Deering
[Deering]. The MOSPF specification is documented in [MOSPF].
1.1. Characteristics of the multicast datagram's
As a multicast datagram is forwarded along its shortest-path tree
the datagram is delivered to each member of the destination
group. In MOSPF, the forwarding of the multicast datagram has
following properties
o The path taken by a multicast datagram depends both on
datagram's source and its multicast destination.
source/destination routing, this is in contrast to most
datagram forwarding algorithms (like OSPF) that
based solely on destination
o The path taken between the datagram's source and any
destination group member is the least cost path available.
is expressed in terms of the OSPF link-state metric
o MOSPF takes advantage of any commonality of least cost
to destination group members. However, when members of
multicast group are spread out over multiple networks,
multicast datagram must at times be replicated. This
is performed as few times as possible (at the tree branches),
taking maximum advantage of common path segments
o For a given multicast datagram, all routers calculate
identical shortest-path tree. This is possible since
shortest-path tree is rooted at the datagram source,
Moy [Page 2]
RFC 1585 MOSPF: Analysis and Experience March 1994
of being rooted at the calculating router (as is done in
unicast case). Tie-breakers have been defined to
that, when several equal-cost paths exist, all routers
on which single path to use. As a result, there is a
path between the datagram's source and any
destination group member. This means that, unlike OSPF'
treatment of regular (unicast) IP data traffic, there is
provision for equal-cost multipath
o While MOSPF optimizes the path to any given group member,
does not necessarily optimize the use of the internetwork
a whole. To do so, instead of calculating source-
shortest-path trees, something similar to a minimal
tree (containing only the group members) would need to
calculated. This type of minimal spanning tree is called
Steiner tree in the literature. For a comparison
shortest-path tree routing to routing using Steiner trees
see [Deering2] and [Bharath-Kumar].
o When forwarding a multicast datagram, MOSPF conforms to
link-layer encapsulation standards for IP
datagrams as specified in "Host extensions for IP multicasting
([RFC 1112]), "Transmission of IP datagrams over
SMDS Service" ([RFC 1209]) and "Transmission of IP and
over FDDI Networks" ([RFC 1390]). In particular, for
and FDDI the explicit mapping between IP
addresses and data-link multicast addresses is used
1.2. Miscellaneous
This section lists, in no particular order, the other
features that the MOSPF protocol supports
o MOSPF routers can be mixed within an Autonomous System (
even within a single OSPF area) with non-multicast
routers. When this is done, all routers will interoperate
the routing of unicasts. Unicast routing will not
affected by this mixing; all unicast paths will be the
as before the introduction of multicast. This mixing
multicast and non-multicast routers enables
introduction of a multicast capability into an internetwork
However, it should be noted that some configurations of
and non-MOSPF routers may produce unexpected failures
multicast routing (see Section 6.1 of [MOSPF]).
o MOSPF does not include the ability to tunnel
datagrams through non-multicast routers. A tunneling
has proved valuable when used by the DVMRP protocol in
Moy [Page 3]
RFC 1585 MOSPF: Analysis and Experience March 1994
MBONE. However, it is assumed that, since MOSPF is an intra-
protocol, multicast can be turned on in enough of the
System's routers to achieve the required connectivity
resorting to tunneling. The more centralized control that
in most Autonomous Systems, when compared to the Internet as
whole, should make this possible
o In addition to calculating a separate datagram path for
[source network, multicast destination] combination,
can also vary the path based on IP Type of Service (TOS).
with OSPF unicast routing, TOS-based multicast routing
optional, and routers supporting it can be freely mixed
those that don't
o MOSPF supports all network types that are supported by the
OSPF protocol: broadcast networks, point-to-points networks
non-broadcast multi-access (NBMA) networks. Note however
IGMP is not defined on NBMA networks, so while these
can support the forwarding of multicast datagrams, they
support directly connected group members
o MOSPF supports all Autonomous System configurations that
supported by the base OSPF protocol. In particular, an
for forwarding multicast datagrams between OSPF
is included. Also, areas with configured virtual links
be used for transit multicast traffic
o A way of forwarding multicast datagrams across
System boundaries has been defined. This means that a
datagram having an external source can still be
throughout the Autonomous System. Facilities also exist
forwarding locally generated datagrams to Autonomous System
points, from which they can be further distributed.
effectiveness of this support will depend upon the nature of
inter-AS multicast routing protocol. The one assumption
has been made is that the inter-AS multicast routing
will operate in an reverse path forwarding (RPF) fashion
namely, that multicast datagrams originating from an
source will enter the Autonomous System at the same place
unicast datagrams destined for that source will exit
o To deal with the fact that the external unicast and
topologies will be different for some time to come,
way to indicate that a route is available for multicast
not unicast (or vice versa) has been defined. This for
would allow a MOSPF system to use DVMRP as its inter-
multicast routing protocol, while using BGP as its inter-
unicast routing protocol
Moy [Page 4]
RFC 1585 MOSPF: Analysis and Experience March 1994
o For those physical networks that have been assigned
IP network/subnet numbers, multicast routing can be
on all but one OSPF interface to the physical network.
avoids unwanted replication of multicast datagrams
o For those networks residing on Autonomous System boundaries
which may be running multiple multicast routing
(or multiple copies of the same multicast routing protocol),
MOSPF can be configured to encapsulate multicast
with unicast (rather than multicast) link-level destinations
This also avoids unwanted replication of multicast datagrams
o MOSPF provides an optimization for IP multicast's "
ring search" (sometimes called "TTL scoping") procedure.
an expanding ring search, an application finds the
server by sending out successive multicasts, each with
larger TTL. The first responding server will then be
closest (in terms of hops, but not necessarily in terms
the OSPF metric). MOSPF minimizes the network
consumed by an expanding ring search by refusing to
multicast datagrams whose TTL is too small to ever reach
group member
2. Security
All MOSPF protocol packet exchanges (excluding IGMP) are specified
the base OSPF protocol, and as such are authenticated. For
discussion of OSPF's authentication mechanism, see Appendix D
[OSPF].
3. MIB
Management support for MOSPF has been added to the base OSPF V2
[OSPF MIB]. These additions consist of the ability to read and
the configuration parameters specified in Section B of [MOSPF],
together with the ability to dump the new group-membership-LSAs
4.
There is currently one MOSPF implementation, written by Proteon, Inc
It was released for general use in April 1992. It is a full
implementation, with the exception of TOS-based multicast routing.
also does not contain an inter-AS multicast routing protocol
The multicast applications included with the Proteon
implementation include: a multicast pinger, console commands so
the router itself can join and leave multicast groups (and so
to multicast pings), and the ability to send SNMP traps to
Moy [Page 5]
RFC 1585 MOSPF: Analysis and Experience March 1994
multicast address. Proteon is also using IP multicast to support
tunneling of other protocols over IP. For example, source
bridging is tunneled over a MOSPF domain, using one IP
address for explorer frames and mapping the segment/bridge found in
specifically-routed frame's RIF field to other IP
addresses. This last application has proved popular, since
provides a lightweight transport that is resistant to reordering
The Proteon MOSPF implementation is currently running
approximately a dozen sites, each site consisting of 10-20 routers
Table 1 gives a comparison between the code size of Proteon's
OSPF implementation and its MOSPF implementation. Two dimensions
lines of C bytes of 68020 object
___________________________________________________
OSPF base 11,693 63,160
MOSPF 15,247 81,956
Table 1: Comparison of OSPF and MOSPF code
size are indicated: lines of C (comments and blanks included),
bytes of 68020 object code. In both cases, the multicast
to OSPF have engendered a 30% size increase
Note that in these sizes, the code used to configure and monitor
implementation has been included. Also, in the MOSPF code
figure, the IGMP implementation has been included
5.
Figure 1 shows the topology that was used for the initial
of Proteon's MOSPF implementation. It consists of seven
routers, interconnected by ethernets, token rings, FDDIs and
lines. The applications used to test the routing were multicast
and the sending of traps to a multicast address (the box
"NAZ" was a network analyzer that was occasionally sending IGMP
Membership Reports and then continuously receiving multicast
traps). The "vat" application was also used on workstations (
running the DVMRP "mrouted" daemon; see "Distance Vector
Routing Protocol", [RFC 1075]) which were multicasting packet
across the MOSPF domain
Moy [Page 6]
RFC 1585 MOSPF: Analysis and Experience March 1994
The MOSPF features tested in this setup were
o Re-routing in response to topology changes
o Path verification after altering costs
o Routing multicast datagrams between areas
o Routing multicast datagrams to and from external addresses
o The various tiebreakers employed when constructing
shortest-path trees
o MOSPF over non-broadcast multi-access networks
o Interoperability of MOSPF and non-multicast OSPF routers
+---+
+-------------------------------|RT1|
| +---+
| +---------+ |
| | |
| +---+ +---+ +---+ |
| |RT5|---------|RT2| |NAZ| |
| +---+ +----+---+ +---+ |
| | | | |
| | +------------------------+
| | | +
| | | |
| | | | +---+
| +------------+ + | |--|RT7|
| | | | | +---+
| +---+ | +---+ |
| |RT4|--------|-----------|RT3|----|
| +---+ | +---+ |
| | |
| + + |
| | +---+ |
+---------------|-----------|RT6|------------|
| +---+ |
+ +
Figure 1: Initial MOSPF test
Moy [Page 7]
RFC 1585 MOSPF: Analysis and Experience March 1994
Due to the commercial tunneling applications developed by
that use IP multicast, MOSPF has been deployed in a number
operational but non-Internet-connected sites. MOSPF has been
deployed in some Internet-connected sites (e.g., OARnet) for
purposes. The desire of these sites is to use MOSPF to attach to
"mbone". However, an implementation of both MOSPF and DVMRP in
same box is needed; without this one way communication has
achieved (sort of like lecture mode in vat) by configuring
static routes in the MOSPF implementation. The problem is that
is no current way to inject the MOSPF source information into DVMRP
The MOSPF features that have not yet been tested are
o The interaction between MOSPF and virtual links
o Interaction between MOSPF and other multicast routing
(e.g., DVMRP).
o TOS-based routing in MOSPF
6. A brief analysis of MOSPF
MOSPF uses the Dijkstra algorithm to calculate the path of
multicast datagram through any given OSPF area. This
encompasses all the transit nodes (routers and networks) in the area
its cost scales as O(N*log(N)) where N is the number of transit
(same as the cost of the OSPF unicast intra-area
calculation). This is the cost of a single path calculation; however
MOSPF calculates a separate path for each [source network,
destination, TOS] tuple. This is potentially a lot of
calculations
MOSPF proposes to deal with this calculation burden by
datagram paths in an "on demand" fashion. That is, the path
calculated only when receiving the first datagram in a stream.
the calculation, the results are cached for use by later
datagrams. This on demand calculation alleviates the cost of
routing calculations in two ways: 1) It spreads the
calculations out over time and 2) the router does fewer calculations
since it does not even calculate the paths of datagrams whose
will not even touch the router
Cache entries need never be timed out, although they are removed
topological changes. If an implementation chooses to limit
amount of memory consumed by the cache, probably by removing
entries, care must be taken to ensure that cache thrashing does
occur
Moy [Page 8]
RFC 1585 MOSPF: Analysis and Experience March 1994
The effectiveness of this "on demand" calculation will need to
proven over time, as multicast usage and traffic patterns become
evident
As a simple example, suppose an OSPF area consists of 200 routers
Suppose each router represents a site, and each site is
simultaneously with three other local sites (inside the area) in
video conference. This gives 200/4 = 50 groups, and 200
datagram trees. Assuming each datagram tree goes through every
(which probably won't be true), each router will be doing 200
Dijkstras initially (and on internal topology changes). The time
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 be done at once, it will take 3 seconds total on
10 mips processor. In contrast, assuming each video stream
64Kb/sec, the routers will constantly forward 12Mb/sec of
data (the cost of this soon dwarfing the cost of the Dijkstras).
In this example there are also 200 group-membership-LSAs in the area
since each group membership-LSA is around 64 bytes, this adds 64*200
= 12K bytes to the OSPF link state database
Other things to keep in mind when evaluating the cost of MOSPF'
routing calculation are
o Assuming that the guidelines of "OSPF protocol analysis" ([
1245]) are followed and areas are limited to 200 nodes, the
of the Dijkstra will not grow unbounded, but will instead
capped at the Dijkstra for 200 nodes. One need then worry
the number of Dijkstras, which is determined by the number
[datagram source, multicast destination] combinations
o A datagram whose destination has no group members in the
can still be forwarded through the MOSPF system. However,
Dijkstra calculation here depends only on the [datagram source
TOS], since the datagram will be forwarded along to "wild-
receivers" only. Since the number of group members in a 200
router area is probably also bounded, the possibility
unbounded calculation growth lies in the number of
datagram sources. (However, it should be noted that some
multicast applications, such as distributed computing, may
a large number of short-lived multicast groups).
o By collapsing routing information before importing it into
area/AS, the number of sources can be reduced dramatically.
particular, if the AS relies on a default external route,
external sources will be covered by a single Dijkstra
(the one using 0.0.0.0 as the source).
Moy [Page 9]
RFC 1585 MOSPF: Analysis and Experience March 1994
One other factor to be considered in MOSPF scaling is how often
entries need to be recalculated, as a result of a network
change. The rules for MOSPF cache maintenance are explained
Section 13 of [MOSPF]. Note that the further away the topology
happens from the calculating router, the fewer cache entries need
be recalculated. For example, if an external route changes,
fewer cache entries need to be purged as compared to a change in
MOSPF domain's internal link. For scaling purposes, this is
the desired behavior. Note that "OSPF protocol analysis" ([RFC 1245])
bears this out when it shows that changes in external routes (on
order of once a minute for the networks surveyed) are much
frequent than internal changes (between 15 and 50 minutes for
networks surveyed).
7. Known
The following are known difficulties with the MOSPF protocol
o When a MOSPF router itself contains multicast applications,
choice of its application datagrams' source addresses should
made with care. Due to OSPF's representation of serial lines
using a serial line interface address as source can lead
excess data traffic on the serial line. In fact, using
interface address as source can lead to excess traffic, owing
MOSPF's decision to always multicast the packet onto the
network as part of the forwarding process (see Section 11.3
[MOSPF]). However, optimal behavior can be achieved by
the router an interface-independent address, and using this
the datagram source
This concern does not apply to regular IP hosts (i.e.,
that are not MOSPF routers).
o It is necessary to ensure, when mixing MOSPF and non-
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
group-membership-LSAs be flooded over the LAN. This can be
operational nuisance, since OSPF's Designated Router
algorithm is designed to discourage Designated Router transitions
rather than to guarantee that certain routers
Designated Router. However, assigning a DR Priority of 0 to
non-multicast routers will always guarantee that a MOSPF
is selected as Designated Router
Moy [Page 10]
RFC 1585 MOSPF: Analysis and Experience March 1994
8. Future
In the future, it is expected that the following work will be done
the MOSPF protocol
o More analysis of multicast traffic patterns needs to be done,
order to see whether the MOSPF routing calculations will pose
undue processing burden on multicast routers. If necessary
further ways to ease this burden may need to be defined.
suggestion that has been made is to revert to reverse
forwarding when the router is unable to calculate the
MOSPF forwarding cache entries
o Experience needs to be gained with the interactions between
multicast routing algorithms (e.g., MOSPF and DVMRP).
o Additional MIB support for the retrieval of forwarding
entries, along the lines of the "IP forwarding table MIB" ([
1354]), would be useful
Moy [Page 11]
RFC 1585 MOSPF: Analysis and Experience March 1994
9.
[Bharath-Kumar] Bharath-Kumar, K., and J. Jaffe, "Routing
multiple destinations in Computer Networks",
Transactions on Communications, COM-31[3],
1983.
[Deering] Deering, S., "Multicast Routing in
and Extended LANs", SIGCOMM Summer 1988
Proceedings, August 1988.
[Deering2] Deering, S., "Multicast Routing in a
Internetwork", Stanford Technical
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
Information Base", RFC 1253, ACC, Computer
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",
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
Datagrams over the SMDS Service", RFC 1209,
Communications Research, March 1991.
[RFC 1245] Moy, J., Editor, "OSPF Protocol Analysis",
1245, Proteon, Inc., July 1991.
[RFC 1246] Moy, J., Editor, "Experience with the
Protocol", RFC 1245, Proteon, Inc., July 1991.
[RFC 1264] Hinden, R., "Internet Routing
Standardization Criteria", RFC 1264, BBN,
1991.
Moy [Page 12]
RFC 1585 MOSPF: Analysis and Experience March 1994
[RFC 1390] Katz, D., "Transmission of IP and ARP over
Networks", RFC 1390, cisco Systems, Inc.,
1993.
[RFC 1354] Baker, F., "IP Forwarding Table MIB", RFC 1354,
ACC, July 1992.
Security
Security issues are not discussed in this memo, tho see Section 2.
Author's
John
Proteon, Inc
9 Technology
Westborough, MA 01581
Phone: (508) 898-2800
EMail: jmoy@proteon.
Moy [Page 13]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
