rfc1584.txt

来自「著名的RFC文档,其中有一些文档是已经翻译成中文的的.」· 文本 代码 · 共 1,306 行 · 第 1/5 页

        loosely describes both of these possible mappings as data-link
        multicast.

        The following terms are also used throughout this document:

        o   Non-multicast router. A router running OSPF Version 2, but
            not the multicast extensions. These routers do not forward
            multicast datagrams, but can interoperate with MOSPF routers
            in the forwarding of unicast packets. Routers running the
            MOSPF protocol are referred to herein as either multicast-
            capable routers or MOSPF routers.

        o   Non-broadcast networks. A network supporting the attachment
            of more than two stations, but not supporting the delivery



Moy                                                             [Page 5]

RFC 1584              Multicast Extensions to OSPF            March 1994


            of a single physical datagram to multiple destinations
            (i.e., not supporting data-link multicast). [OSPF] describes
            these networks as non-broadcast, multi-access networks. An
            example of a non-broadcast network is an X.25 PDN.

        o   Transit network. A network having two or more OSPF routers
            attached.  These networks can forward data traffic that is
            neither locally-originated nor locally-destined. In OSPF,
            with the exception of point-to-point networks and virtual
            links, the neighborhood of each transit network is described
            by a network links advertisement (network-LSA).

        o   Stub network. A network having only a single OSPF router
            attached. A network belonging to an OSPF system is either a
            transit or a stub network, but never both.

    1.2.  Acknowledgments

        The multicast extensions to OSPF are based on Link-State
        Multicast Routing algorithm presented in [Deering]. In addition,
        the [Deering] paper contains a section on Hierarchical Multicast
        Routing (providing the ideas for MOSPF's inter-area multicasting
        scheme) and several Distance Vector (also called Bellman-Ford)
        multicast algorithms. One of these Distance Vector multicast
        algorithms, Truncated Reverse Path Broadcasting, has been
        implemented in the Internet (see [RFC 1075]).

        The MOSPF protocol has been developed by the MOSPF Working Group
        of the Internet Engineering Task Force. Portions of this work
        have been supported by DARPA under NASA contract NAG 2-650.

2.  Multicast routing in MOSPF

    This section describes MOSPF's basic multicast routing algorithm.
    The basic algorithm, run inside a single OSPF area, covers the case
    where the source of the multicast datagram is inside the area
    itself. Within the area, the path of the datagram forms a tree
    rooted at the datagram source.

    2.1.  Routing characteristics

        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



Moy                                                             [Page 6]

RFC 1584              Multicast Extensions to OSPF            March 1994


            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. For example, if the OSPF metric represents delay, a
            minimum delay path is chosen. OSPF metrics are configurable.
            A metric is assigned to each outbound router interface,
            representing the cost of sending a packet on that interface.
            The cost of a path is the sum of its constituent (outbound)
            router interfaces[1].

        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. 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   On each packet hop, MOSPF normally forwards IP multicast
            datagrams as data-link multicasts. There are two exceptions.
            First, on non-broadcast networks, since there are no data-
            link multicast/broadcast services the datagram must be
            forwarded to specific MOSPF neighbors (see Section 2.3.3).
            Second, a MOSPF router can be configured to forward IP
            multicasts on specific networks as data-link unicasts, in
            order to avoid datagram replication in certain anomalous
            situations (see Section 6.4).

        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].



Moy                                                             [Page 7]

RFC 1584              Multicast Extensions to OSPF            March 1994


    2.2.  Sample path of a multicast datagram

        As an example of multicast datagram routing in MOSPF, consider
        the sample Autonomous System pictured in Figure 1. This figure
        has been taken from the OSPF specification (see [OSPF]). The
        larger rectangles represent routers, the smaller rectangles
        hosts. Oblongs and circles represent multi-access networks[2].
        Lines joining routers are point-to-point serial connections. A
        cost has been assigned to each outbound router interface.

        All routers in Figure 1 are assumed to be running MOSPF. A
        number of hosts have been added to the figure. The hosts
        labelled Ma have joined a particular multicast group (call it
        Group A) via the IGMP protocol.  These hosts are located on
        networks N2, N6 and N11. Similarly, using IGMP the hosts
        labelled Mb have joined a separate multicast group B; these
        hosts are located on networks N1, N2 and N3. Note that hosts can
        join multiple multicast groups; it is only for clarity of
        presentation that each host has joined at most one multicast
        group in this example.  Also, hosts H2 through H5 have been
        added to the figure to serve as sources for multicast datagrams.
        Again, the datagrams' sources have been made separate from the
        group members only for clarity of presentation.

        To illustrate the forwarding of a multicast datagram, suppose
        that Host H2 (attached to Network N4) sends a multicast datagram
        to multicast group B. This datagram originates as a data-link
        layer multicast on Network N4. Router RT3, being a multicast
        router, has "opened up" its interface data-link multicast
        filters. It therefore receives the multicast datagram, and
        attempts to forward it to the members of multicast group B
        (located on networks N1, N2 and N3). This is accomplished by
        sending a single copy of the datagram onto Network N3, again as
        a data-link multicast[3].  Upon receiving the multicast datagram
        from RT3, routers RT1 and RT2 will then multicast the datagram
        on their connected stub networks (N1 and N2 respectively).  Note
        that, since the datagram is sent onto Network N3 as a data-link
        multicast, Router RT4 will also receive a copy. However, it will
        not forward the datagram, since it does not lie on a shortest
        path between the source (Host H2) and any members of multicast
        group B.

        Note that the path of the multicast datagram depends on the
        datagram's source network. If the above multicast datagram was
        instead originated by Host H3, the path taken would be
        identical, since hosts H2 and H3 lie on the same network
        (Network N4). However, if the datagram was originated by Host
        H4, its path would be different. In this case, when Router RT3



Moy                                                             [Page 8]

RFC 1584              Multicast Extensions to OSPF            March 1994





                 +
                 | 3+---+    +--+  +--+       N12      N14
               N1|--|RT1|\1  |Mb|  |H4|         \ N13 /
                _|  +---+ \  +--+ /+--+         8\ |8/8
               | +         \ _|__/                \|/
             +--+   +--+    /    \   1+---+8    8+---+6
             |Mb|   |Mb|   *  N3  *---|RT4|------|RT5|--------+
             +--+  /+--+    \____/    +---+      +---+        |
                  +         /   |                  |7         |
                  | 3+---+ /    |                  |          |
                N2|--|RT2|/1    |1                 |6         |
                __|  +---+    +---+8            6+---+        |
               |  +           |RT3|--------------|RT6|        |
             +--+    +--+     +---+     +--+     +---+        |
             |Ma|    |H3|_      |2     _|H2|     Ia|7         |
             +--+    +--+ \     |     / +--+       |          |
                           +---------+             |          |
                               N4                  |          |
                                                   |          |
                                                   |          |
                       N11                         |          |
                   +---------+                     |          |
                        |     \                    |          |    N12
                        |3     +--+                |          |6 2/
                      +---+    |Ma|                |        +---+/
                      |RT9|    +--+                |        |RT7|---N15
                      +---+                        |        +---+ 9
                        |1                   +     |          |1
                       _|__                  |   Ib|5       __|_   +--+
                      /    \      1+----+2   |  3+----+1   /    \--|Ma|
                     *  N9  *------|RT11|----|---|RT10|---*  N6  * +--+
                      \____/       +----+    |   +----+    \____/
                        |                    |                |
                        |1                   +                |1
             +--+   10+----+                N8              +---+
             |H1|-----|RT12|                                |RT8|
             +--+SLIP +----+                                +---+  +--+
                        |2                                    |4  _|H5|
                        |                                     |  / +--+
                   +---------+                            +--------+
                       N10                                    N7

                    Figure 1: A sample MOSPF configuration





Moy                                                             [Page 9]

RFC 1584              Multicast Extensions to OSPF            March 1994


        receives the datagram, RT3 will drop the datagram instead of
        forwarding it (since RT3 is no longer on the shortest path to
        any member of Group B).

        Note that the path of the multicast datagram also depends on the
        destination multicast group. If Host H2 sends a multicast to
        Group A, the path taken is as follows. The datagram again starts
        as a multicast on Network N4. Router RT3 receives it, and
        creates two copies. One is sent onto Network N3 which is then
        forwarded onto Network N2 by RT2. The other copy is sent to
        Router RT10 (via RT6), where the datagram is again split,
        eventually to be delivered onto networks N6 and N11. Note that,
        although multiple copies of the datagram are produced, the
        datagram itself is not modified (except for its IP TTL) as it is
        forwarded. No encapsulation of the datagram is performed; the
        destination of the datagram is always listed as the multicast