rfc1584.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,264 行 · 第 1/5 页

Network Working Group                                             J. Moy
Request for Comments: 1584                                 Proteon, Inc.
Category: Standards Track                                     March 1994


                      Multicast Extensions to OSPF



Status of this Memo

    This document specifies an Internet standards track protocol for the
    Internet community, and requests discussion and suggestions for
    improvements.  Please refer to the current edition of the "Internet
    Official Protocol Standards" (STD 1) for the standardization state
    and status of this protocol.  Distribution of this memo is
    unlimited.

Abstract

    This memo documents enhancements to the OSPF protocol enabling the
    routing of IP multicast datagrams. In this proposal, an IP multicast
    packet is routed based both on the packet's source and its multicast
    destination (commonly referred to as source/destination routing). As
    it is routed, the multicast packet follows a shortest path to each
    multicast destination. During packet forwarding, any commonality of
    paths is exploited; when multiple hosts belong to a single multicast
    group, a multicast packet will be replicated only when the paths to
    the separate hosts diverge.

    OSPF, a link-state routing protocol, provides a database describing
    the Autonomous System's topology. A new OSPF link state
    advertisement is added describing the location of multicast
    destinations. A multicast packet's path is then calculated by
    building a pruned shortest-path tree rooted at the packet's IP
    source. These trees are built on demand, and the results of the
    calculation are cached for use by subsequent packets.

    The multicast extensions are built on top of OSPF Version 2. The
    extensions have been implemented so that a multicast routing
    capability can be introduced piecemeal into an OSPF Version 2
    routing domain. Some of the OSPF Version 2 routers may run the
    multicast extensions, while others may continue to be restricted to
    the forwarding of regular IP traffic (unicasts).

    Please send comments to [e-mail].





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


Table of Contents

    1       Introduction ........................................... 4
    1.1     Terminology ............................................ 5
    1.2     Acknowledgments ........................................ 6
    2       Multicast routing in MOSPF ............................. 6
    2.1     Routing characteristics ................................ 6
    2.2     Sample path of a multicast datagram .................... 8
    2.3     MOSPF forwarding mechanism ............................ 10
    2.3.1   IGMP interface: the local group database .............. 10
    2.3.2   A datagram's shortest-path tree ....................... 14
    2.3.3   Support for Non-broadcast networks .................... 16
    2.3.4   Details concerning forwarding cache entries ........... 16
    3       Inter-area multicasting ............................... 18
    3.1     Extent of group-membership-LSAs ....................... 19
    3.2     Building inter-area datagram shortest-path trees ...... 22
    4       Inter-AS multicasting ................................. 27
    4.1     Building inter-AS datagram shortest-path trees ........ 28
    4.2     Stub area behavior .................................... 30
    4.3     Inter-AS multicasting in a core Autonomous System ..... 31
    5       Modelling internal group membership ................... 31
    6       Additional capabilities ............................... 33
    6.1     Mixing with non-multicast routers ..................... 34
    6.2     TOS-based multicast ................................... 35
    6.3     Assigning multiple IP networks to a physical network .. 36
    6.4     Networks on Autonomous System boundaries .............. 37
    6.5     Recommended system configuration ...................... 38
    7       Basic implementation requirements ..................... 40
    8       Protocol data structures .............................. 40
    8.1     Additions to the OSPF area structure .................. 41
    8.2     Additions to the OSPF interface structure ............. 42
    8.3     Additions to the OSPF neighbor structure .............. 43
    8.4     The local group database .............................. 43
    8.5     The forwarding cache .................................. 44
    9       Interaction with the IGMP protocol .................... 45
    9.1     Sending IGMP Host Membership Queries .................. 46
    9.2     Receiving IGMP Host Membership Reports ................ 46
    9.3     Aging local group database entries .................... 47
    9.4     Receiving IGMP Host Membership Queries ................ 47
    10      Group-membership-LSAs ................................. 48
    10.1    Constructing group-membership-LSAs .................... 49
    10.2    Flooding group-membership-LSAs ........................ 52
    11      Detailed description of multicast datagram forwarding . 52
    11.1    Associating a MOSPF interface with a received datagram  55
    11.2    Locating the source network ........................... 55
    11.3    Forwarding locally originated multicasts .............. 57
    12      Construction of forwarding cache entries .............. 58
    12.1    The Vertex data structure ............................. 59



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


    12.2    The SPF calculation ................................... 60
    12.2.1  Candidate list Initialization: Case SourceIntraArea ... 65
    12.2.2  Candidate list Initialization: Case SourceInterArea1 .. 66
    12.2.3  Candidate list Initialization: Case SourceInterArea2 .. 66
    12.2.4  Candidate list Initialization: Case SourceExternal .... 67
    12.2.5  Candidate list Initialization: Case SourceStubExternal  70
    12.2.6  Processing labelled vertices .......................... 70
    12.2.7  Merging datagram shortest-path trees .................. 71
    12.2.8  TOS considerations .................................... 72
    12.2.9  Comparison to the unicast SPF calculation ............. 74
    12.3    Adding local database entries to the forwarding cache   75
    13      Maintaining the forwarding cache ...................... 76
    14      Other additions to the OSPF specification ............. 77
    14.1    The Designated Router ................................. 77
    14.2    Sending Hello packets ................................. 78
    14.3    The Neighbor state machine ............................ 78
    14.4    Receiving Database Description packets ................ 78
    14.5    Sending Database Description packets .................. 79
    14.6    Originating Router-LSAs ............................... 79
    14.7    Originating Network-LSAs .............................. 79
    14.8    Originating Summary-link-LSAs ......................... 80
    14.9    Originating AS external-link-LSAs ..................... 80
    14.10   Next step in the flooding procedure ................... 81
    14.11   Virtual links ......................................... 81
    15      References ............................................ 83
            Footnotes ............................................. 84
    A       Data Formats .......................................... 88
    A.1     The Options field ..................................... 89
    A.2     Router-LSA ............................................ 91
    A.3     Group-membership-LSA .................................. 93
    B       Configurable Constants ................................ 95
    B.1     Global parameters ..................................... 95
    B.2     Router interface parameters ........................... 95
    C       Sample datagram shortest-path trees ................... 97
    C.1     An intra-area tree .................................... 98
    C.2     The effect of areas .................................. 100
    C.3     The effect of virtual links .......................... 101
            Security Considerations .............................. 102
            Author's Address ..................................... 102












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


1.  Introduction

    This memo documents enhancements to OSPF Version 2 to support IP
    multicast routing. The enhancements have been added in a backward-
    compatible fashion; routers running the multicast additions will
    interoperate with non-multicast OSPF routers when forwarding regular
    (unicast) IP data traffic. The protocol resulting from the addition
    of the multicast enhancements to OSPF is herein referred to as the
    MOSPF protocol.

    IP multicasting is an extension of LAN multicasting to a TCP/IP
    internet. Multicasting support for TCP/IP hosts has been specified
    in [RFC 1112]. In that document, multicast groups are represented by
    IP class D addresses. Individual TCP/IP hosts join (and leave)
    multicast groups through the Internet Group Management Protocol
    (IGMP, also specified in [RFC 1112]). A host need not be a member of
    a multicast group in order to send datagrams to the group. Multicast
    datagrams are to be delivered to each member of the multicast group
    with the same "best-effort" delivery accorded regular (unicast) IP
    data traffic.

    MOSPF provides the ability to forward multicast datagrams from one
    IP network to another (i.e., through internet routers). MOSPF
    forwards a multicast datagram on the basis of both the datagram's
    source and destination (this is sometimes called source/destination
    routing). The OSPF link state database provides a complete
    description of the Autonomous System's topology. By adding a new
    type of link state advertisement, the group-membership-LSA, the
    location of all multicast group members is pinpointed in the
    database. The path of a multicast datagram can then be calculated by
    building a shortest-path tree rooted at the datagram's source. All
    branches not containing multicast members are pruned from the tree.
    These pruned shortest-path trees are initially built when the first
    datagram is received (i.e., on demand).  The results of the shortest
    path calculation are then cached for use by subsequent datagrams
    having the same source and destination.

    OSPF allows an Autonomous System to be split into areas. However,
    when this is done complete knowledge of the Autonomous System's
    topology is lost. When forwarding multicasts between areas, only
    incomplete shortest-path trees can be built. This may lead to some
    inefficiency in routing. An analogous situation exists when the
    source of the multicast datagram lies in another Autonomous System.
    In both cases (i.e., the source of the datagram belongs to a
    different OSPF area, or to a different Autonomous system) the
    neighborhood immediately surrounding the source is unknown. In these
    cases the source's neighborhood is approximated by OSPF summary link
    advertisements or by OSPF AS external link advertisements



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


    respectively.

    Routers running MOSPF can be intermixed with non-multicast OSPF
    routers. Both types of routers can interoperate when forwarding
    regular (unicast) IP data traffic. Obviously, the forwarding extent
    of IP multicasts is limited by the number of MOSPF routers present
    in the Autonomous System (and their interconnection, if any). An
    ability to "tunnel" multicast datagrams through non-multicast
    routers is not provided. In MOSPF, just as in the base OSPF
    protocol, datagrams (multicast or unicast) are routed "as is" --
    they are not further encapsulated or decapsulated as they transit
    the Autonomous System.

    1.1.  Terminology

        This memo uses the terminology listed in section 1.2 of [OSPF].
        For this reason, terms such as "Network", "Autonomous System"
        and "link state advertisement" are assumed to be understood. In
        addition, the abbreviation LSA is used for "link state
        advertisement". For example, router links advertisements are
        referred to as router-LSAs and the new link state advertisement
        describing the location of members of a multicast group is
        referred to as a group-membership-LSA.

        [RFC 1112] discusses the data-link encapsulation of IP multicast