doc: Add RFC documents

1 files changed, 731 insertions, 0 deletions

diff --git a/doc/rfc/rfc1585.txt b/doc/rfc/rfc1585.txt
new file mode 100644
index 0000000..5a251e1
--- /dev/null
+++ b/doc/rfc/rfc1585.txt
@@ -0,0 +1,731 @@
+
+
+
+
+
+
+Network Working Group                                             J. Moy
+Request for Comments: 1585                                 Proteon, Inc.
+Category: Informational                                       March 1994
+
+
+                     MOSPF: Analysis and Experience
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  This memo
+   does not specify an Internet standard of any kind.  Distribution of
+   this memo is unlimited.
+
+Abstract
+
+   This memo documents how the MOSPF protocol satisfies the requirements
+   imposed on Internet routing protocols by "Internet Engineering Task
+   Force internet routing protocol standardization criteria" ([RFC
+   1264]).
+
+   Please send comments to mospf@gated.cornell.edu.
+
+1.  Summary of MOSPF features and algorithms
+
+   MOSPF is an enhancement of OSPF V2, enabling the routing of IP
+   multicast datagrams.  OSPF is a link-state (unicast) routing
+   protocol, providing a database describing the Autonomous System's
+   topology.  IP multicast is an extension of LAN multicasting to a
+   TCP/IP Internet.  IP Multicast permits an IP host to send a single
+   datagram (called an IP multicast datagram) that will be delivered to
+   multiple destinations.  IP multicast datagrams are identified as
+   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 IP
+   multicasting are specified in "Host extensions for IP multicasting"
+   ([RFC 1112]).  That document defines a protocol, the Internet Group
+   Management Protocol (IGMP), that enables hosts to dynamically join
+   and leave multicast groups.
+
+   MOSPF routers use the IGMP protocol to monitor multicast group
+   membership on local LANs through the sending of IGMP Host Membership
+   Queries and the reception of IGMP Host Membership Reports.  A MOSPF
+   router then distributes this group location information throughout
+   the routing domain by flooding a new type of OSPF link state
+   advertisement, the group-membership-LSA (type 6). This in turn
+   enables the MOSPF routers to most efficiently forward a multicast
+
+
+
+Moy                                                             [Page 1]
+
+RFC 1585             MOSPF: Analysis and Experience           March 1994
+
+
+   datagram to its multiple destinations: each router calculates the
+   path of the multicast 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 the
+   routers, these trees are built "on demand", i.e., the first time a
+   datagram having 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 internal to a single Autonomous System.
+   When supporting IP multicast over the entire Internet, MOSPF would
+   have to be used in concert 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,
+   the datagram is delivered to each member of the destination multicast
+   group. In MOSPF, the forwarding of the multicast datagram has the
+   following properties:
+
+      o The path taken by a multicast datagram depends both on the
+        datagram's source and its multicast destination. Called
+        source/destination routing, this is in contrast to most unicast
+        datagram forwarding algorithms (like OSPF) that route
+        based solely on destination.
+
+      o The path taken 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.
+
+      o 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.
+
+      o For a given multicast datagram, all routers calculate an
+        identical shortest-path tree.  This is possible since the
+        shortest-path tree is rooted at the datagram source, instead
+
+
+
+Moy                                                             [Page 2]
+
+RFC 1585             MOSPF: Analysis and Experience           March 1994
+
+
+        of being rooted 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.
+
+      o 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 so, 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].
+
+      o 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 the MOSPF protocol supports:
+
+      o 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 will interoperate in
+        the routing of unicasts.  Unicast routing will not be
+        affected by this mixing; all unicast paths will be the same
+        as before the introduction of multicast. This mixing of
+        multicast and non-multicast routers enables phased
+        introduction of a 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]).
+
+      o MOSPF does not include the ability to tunnel multicast
+        datagrams through non-multicast routers. A tunneling capability
+        has proved valuable when used by the DVMRP protocol in the
+
+
+
+Moy                                                             [Page 3]
+
+RFC 1585             MOSPF: Analysis and Experience           March 1994
+
+
+        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, when compared to the Internet as a
+        whole, should make this possible.
+
+      o 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 supporting it can be freely mixed with
+        those that don't.
+
+      o 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.
+
+      o 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.
+
+      o 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 will depend upon the nature of the
+        inter-AS multicast routing protocol.  The one assumption that
+        has been made is that the inter-AS multicast routing protocol
+        will operate in an reverse path forwarding (RPF) fashion:
+        namely, that multicast datagrams originating from an external
+        source will enter the Autonomous System at the same place that
+        unicast datagrams destined for that source will exit.
+
+      o To deal with the fact that the 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. This for example
+        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.
+
+
+
+Moy                                                             [Page 4]
+
+RFC 1585             MOSPF: Analysis and Experience           March 1994
+
+
+      o For those 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.
+
+      o For those 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.
+
+      o 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 are authenticated. For a
+   discussion of OSPF's authentication mechanism, see Appendix D of
+   [OSPF].
+
+3.  MIB support
+
+   Management support for MOSPF has been added to the base OSPF V2 MIB
+   [OSPF MIB]. These additions consist of the ability to read and write
+   the configuration parameters specified in Section B of [MOSPF],
+   together with the ability to dump the new group-membership-LSAs.
+
+4.  Implementations
+
+   There is currently one MOSPF implementation, written by Proteon, Inc.
+   It was released for general use in April 1992. It is a full MOSPF
+   implementation, with the exception of TOS-based multicast routing. It
+   also does not contain an inter-AS multicast routing protocol.
+
+   The multicast applications included with the Proteon MOSPF
+   implementation include: a multicast pinger, console commands so that
+   the router itself can join and leave multicast groups (and so respond
+   to multicast pings), and the ability to send SNMP traps to a
+
+
+
+Moy                                                             [Page 5]
+
+RFC 1585             MOSPF: Analysis and Experience           March 1994
+
+
+   multicast address. Proteon is also using IP multicast to support the
+   tunneling of other protocols over IP.  For example, source route
+   bridging is tunneled over a MOSPF domain, using one IP multicast
+   address for explorer frames and mapping the segment/bridge found in a
+   specifically-routed frame's RIF field to other IP multicast
+   addresses.  This last application has proved popular, since it
+   provides a lightweight transport that is resistant to reordering.
+
+   The Proteon MOSPF implementation is currently running in
+   approximately a dozen sites, each site consisting of 10-20 routers.
+
+   Table 1 gives a comparison between the code size of Proteon's base
+   OSPF implementation and its MOSPF implementation. Two dimensions of
+
+                      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
+
+   size are indicated: lines of C (comments and blanks  included),  and
+   bytes  of 68020 object code. In both cases, the multicast extensions
+   to OSPF have engendered a 30% size increase.
+
+   Note that in these sizes, the code used to configure and monitor the
+   implementation has been included. Also, in the MOSPF code size
+   figure, the IGMP implementation has been included.
+
+5.  Testing
+
+   Figure 1 shows the topology that was used for the initial debugging
+   of Proteon's MOSPF implementation.  It consists of seven MOSPF
+   routers, interconnected by ethernets, token rings, FDDIs and serial
+   lines. The applications used to test the routing were multicast ping
+   and the sending of traps to a multicast address (the box labeled
+   "NAZ" was a network analyzer that was occasionally sending IGMP Host
+   Membership Reports and then continuously receiving multicast SNMP
+   traps). The "vat" application was also used on workstations (without
+   running the DVMRP "mrouted" daemon; see "Distance Vector Multicast
+   Routing Protocol", [RFC 1075]) which were multicasting packet voice
+   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 datagram
+       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 setup
+
+
+
+
+
+
+Moy                                                             [Page 7]
+
+RFC 1585             MOSPF: Analysis and Experience           March 1994
+
+
+   Due to the commercial tunneling applications developed by Proteon
+   that use IP multicast, MOSPF has been deployed in a number of
+   operational but non-Internet-connected sites.  MOSPF has been also
+   deployed in some Internet-connected sites (e.g., OARnet) for testing
+   purposes. The desire of these sites is to use MOSPF to attach to the
+   "mbone".  However, an implementation of both MOSPF and DVMRP in the
+   same box is needed; without this 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 that there
+   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 protocols
+       (e.g., DVMRP).
+
+   o   TOS-based routing in MOSPF.
+
+6.  A brief analysis of MOSPF scaling
+
+   MOSPF uses the Dijkstra algorithm to calculate the path of a
+   multicast datagram through any given OSPF area. This calculation
+   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 nodes
+   (same as the cost of the OSPF unicast intra-area routing
+   calculation). This is the cost of a single path calculation; however,
+   MOSPF calculates a separate path for each [source network, multicast
+   destination, TOS] tuple. This is potentially a lot of Dijkstra
+   calculations.
+
+   MOSPF proposes to deal with this calculation burden by calculating
+   datagram paths in an "on demand" fashion. That is, the path is
+   calculated only when receiving the first datagram in a stream.  After
+   the calculation, the results are cached for use by later matching
+   datagrams. This on demand calculation alleviates the cost of the
+   routing calculations in two ways: 1) It spreads the routing
+   calculations out over time and 2) the router does fewer calculations,
+   since it does not even calculate the paths of datagrams whose path
+   will not even touch the router.
+
+   Cache entries need never be timed out, although they are removed on
+   topological changes.  If an implementation chooses to limit the
+   amount of memory consumed by the cache, probably by removing selected
+   entries, care must be taken to ensure that cache thrashing does not
+   occur.
+
+
+
+
+Moy                                                             [Page 8]
+
+RFC 1585             MOSPF: Analysis and Experience           March 1994
+
+
+   The effectiveness of this "on demand" calculation will need to be
+   proven over time, as multicast usage and traffic patterns become more
+   evident.
+
+   As a simple example, suppose an OSPF area consists of 200 routers.
+   Suppose each router represents a site, and each site is participating
+   simultaneously with three other local sites (inside the area) in a
+   video conference. This 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 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 be done at once, it will take 3 seconds total on a
+   10 mips processor. In contrast, assuming each video stream is
+   64Kb/sec, the routers will constantly forward 12Mb/sec of application
+   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's
+   routing calculation are:
+
+   o Assuming that the guidelines of "OSPF protocol analysis" ([RFC
+     1245]) are followed and areas are limited to 200 nodes, the cost
+     of the Dijkstra will not grow unbounded, but will instead be
+     capped at the Dijkstra for 200 nodes.  One need then worry about
+     the number of Dijkstras, which is determined by the number of
+     [datagram source, multicast destination] combinations.
+
+   o A datagram whose destination has no group members in the domain
+     can still be forwarded through the MOSPF system. However, the
+     Dijkstra calculation here depends only on the [datagram source,
+     TOS], since the datagram will be 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 lies in the number of possible
+     datagram sources. (However, it should be noted that some future
+     multicast applications, such as distributed computing, may generate
+     a large number of short-lived multicast groups).
+
+   o By collapsing 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 will be covered by a single Dijkstra calculation
+     (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 cache
+   entries need to be recalculated, as a result of a network topology
+   change. The rules for MOSPF cache maintenance are explained in
+   Section 13 of [MOSPF]. Note that 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, many
+   fewer cache entries need to be purged as compared to a change in a
+   MOSPF domain's internal link. For scaling purposes, this is exactly
+   the desired behavior. Note that "OSPF protocol analysis" ([RFC 1245])
+   bears this out when 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
+
+   The following are known difficulties with the MOSPF protocol:
+
+   o When a MOSPF router itself contains multicast applications, the
+     choice of its application datagrams' source addresses should be
+     made with care.  Due to OSPF's representation of serial lines,
+     using a serial line interface address as source can lead to
+     excess data traffic on the serial line.  In fact, using any
+     interface address as source can lead to excess traffic, owing to
+     MOSPF's decision to always multicast the packet onto the source
+     network as part of the forwarding process (see Section 11.3 of
+     [MOSPF]). However, optimal behavior can be achieved by assigning
+     the router an interface-independent address, and using this as
+     the datagram source.
+
+     This concern does not apply to regular IP hosts (i.e., those
+     that are not MOSPF routers).
+
+   o 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.
+
+
+
+
+
+
+
+Moy                                                            [Page 10]
+
+RFC 1585             MOSPF: Analysis and Experience           March 1994
+
+
+8.  Future work
+
+   In the future, it is expected that the following work will be done on
+   the MOSPF protocol:
+
+   o 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.
+
+   o Experience needs to be gained with the interactions between multiple
+     multicast routing algorithms (e.g., MOSPF and DVMRP).
+
+   o Additional MIB support for the retrieval of forwarding cache
+     entries, along the lines of the "IP forwarding table MIB" ([RFC
+     1354]), would be useful.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moy                                                            [Page 11]
+
+RFC 1585             MOSPF: Analysis and Experience           March 1994
+
+
+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.
+
+
+
+
+
+Moy                                                            [Page 12]
+
+RFC 1585             MOSPF: Analysis and Experience           March 1994
+
+
+    [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
+
+   Security issues are not 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moy                                                            [Page 13]
+