rfc1584.txt

来自「中、英文RFC文档大全打包下载完全版 .」· 文本 代码 · 共 1,306 行 · 第 1/5 页

TXT
1,306
字号
        the area configuration pictured in Figure 4. The result of        adding the group-membership-LSAs to the area databases yields        the databases pictured in Figures 6 and 7.  Figure 6 shows Area        1's MOSPF database. Figure 7 shows the backbone's MOSPF        database. Superscripts indicate which transit vertices have been        advertised as requesting particular multicast destinations. A        superscript of "w" indicates that the router is advertising        itself as a wild-card multicast receiver (see below). The dashed        lines are OSPF summary-link-LSAs or AS external-link-LSAs. Note        in Figure 7 that Router RT11 has condensed its routes to        Networks N9-N11 and Host H1 into a single summary-link-LSA.Moy                                                            [Page 19]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         |           . +--+    +--+ \     |     / +--+.      |          |           .               +---------+      .      |          |           .Area 1             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           Virtual + Link           |1       .           . +--+   10+----+              ..N8              +---+      .           . |H1|-----|RT12|              ..                |RT8|      .           . +--+SLIP +----+              ..                +---+  +--+.           .            |2                ..                  |4  _|H5|.           .            |                 ..                  |  / +--+.           .       +---------+            ..              +--------+   .           .           N10          Area 3..Area 2            N7       .           .............................................................                    Figure 4: A sample MOSPF area configurationMoy                                                            [Page 20]RFC 1584              Multicast Extensions to OSPF            March 1994        Suppose an OSPF router has a local group database entry for        [Group Y, Network X]. The router then originates a group-        membership-LSA for Group Y into the area containing Network X.        For example, in the area configuration pictured in Figure 4,        Router RT1 originates a group-membership-LSA for Group B. This        group-membership-LSA is flooded throughout Area 1, and no        further. Likewise, assuming that Router RT3 has been elected        Designated Router for Network N3, RT3 originates a group-        membership-LSA into Area 1 listing the transit Network N3 as        having group members. Note that in the link state database for        Area 1 (Figure 6) both Router RT1 and Network N3 have        accordingly been labelled with Group B.        In OSPF, the area border routers forward routing information and        data traffic between areas. In MOSPF. a subset of the area        border routers, called the inter-area multicast forwarders,        forward group membership information and multicast datagrams        between areas. Whether a given OSPF area border router is also a        MOSPF inter-area multicast forwarder is configuration dependent        (see Section B.1). In Figure 4 we assume that all area border        routers are also inter-area multicast forwarders.        In order to convey group membership information between areas,        inter-area multicast forwarders "summarize" their attached        areas' group membership to the backbone. This is very similar        functionality to the summary-link-LSAs that are generated in the        base OSPF protocol.  An inter-area multicast forwarder        calculates which groups have members in its attached non-        backbone areas. Then, for each of these groups, the inter-area        multicast forwarder injects a group-membership-LSA into the        backbone area. For example, in Figure 4 there are two groups        having members in Area 1: Group A and Group B. For that reason,        both of Area 1's inter-area multicast forwarders (Routers RT3        and RT4) inject group-membership-LSAs for these two groups into        the backbone.  As a result both of these routers are labelled                membership    +------------------+   datagrams                    + > > > >>|     Backbone     |< < < < +                    ^         +------------------+        ^                    ^        /         |          \       ^                    ^       /          |           \      ^               +----^-----+/      +----------+      \+----^-----+               |  Area 1  |       |  Area 2  |       |  Area 3  |               +----------+       +----------+       +----------+                    Figure 5: Inter-area routing architectureMoy                                                            [Page 21]RFC 1584              Multicast Extensions to OSPF            March 1994        with Groups A and B in the backbone link state database (see        Figure 7).        However, unlike the summarization of unicast destinations in the        base OSPF protocol, the summarization of group membership in        MOSPF is asymmetric. While a non-backbone area's group        membership is summarized to the backbone, this information is        not then readvertised into other non-backbone areas. Nor is the        backbone's group membership summarized for the non-backbone        areas. Going back to the example in Figure 4, while the presence        of Area 3's group (Group A) is advertised to the backbone, this        information is not then redistributed to Area 1. In other words,        routers internal to Area 1 have no idea of Area 3's group        membership.        At this point, if no extra functionality was added to MOSPF,        multicast traffic originating in Area 1 destined for Multicast        Group A would never be forwarded to those Group A members in        Area 3. To accomplish this, the notion of wild-card multicast        receivers is introduced. A wild-card multicast receiver is a        router to which all multicast traffic, regardless of multicast        destination, should be forwarded. A router's wild-card multicast        reception status is per-area. In non-backbone areas, all inter-        area multicast forwarders[10] are wild-card multicast receivers.        This ensures that all multicast traffic originating in a non-        backbone area will be forwarded to its inter-area multicast        forwarders, and hence to the backbone area. Since the backbone        has complete knowledge of all areas' group membership, the        datagram can then be forwarded to all group members. Note that        in the backbone itself there is no need for wild-card multicast        receivers[11].  As an example, note that Routers RT3 and RT4 are        wild-card multicast receivers in Area 1 (see Figure 6), while        there are none in the backbone (see Figure 7).        This yields the inter-area routing architecture pictured in        Figure 5.  All group membership is advertised by the non-        backbone areas into the backbone. Likewise, all IP multicast        traffic arising in the non-backbone areas is forwarded to the        backbone. Since at this point group membership information meets        the multicast datagram traffic, delivery of the multicast        datagrams becomes possible.    3.2.  Building inter-area datagram shortest-path trees        When building datagram shortest-path trees in the presence of        areas, it is often the case that the source of the datagram and        (at least some of) the destination group members are in separate        areas. Since detailed topological information concerning oneMoy                                                            [Page 22]RFC 1584              Multicast Extensions to OSPF            March 1994                                  **FROM**                             |RT|RT|RT|RT|RT|RT|                             |1 |2 |3 |4 |5 |7 |N3|                          ----- -------------------                          RT1|  |  |  |  |  |  |0 |                          RT2|  |  |  |  |  |  |0 |                          RT3|  |  |  |  |  |  |0 |                      *   RT4|  |  |  |  |  |  |0 |                      *   RT5|  |  |14|8 |  |  |  |                      T   RT7|  |  |20|14|  |  |  |                      O    N1|3 |  |  |  |  |  |  |                      *    N2|  |3 |  |  |  |  |  |                      *    N3|1 |1 |1 |1 |  |  |  |                           N4|  |  |2 |  |  |  |  |                        Ia,Ib|  |  |15|22|  |  |  |                           N6|  |  |16|15|  |  |  |                           N7|  |  |20|19|  |  |  |                           N8|  |  |18|18|  |  |  |                    N9-N11,H1|  |  |19|16|  |  |  |                          N12|  |  |  |  |8 |2 |  |                          N13|  |  |  |  |8 |  |  |                          N14|  |  |  |  |8 |  |  |                          N15|  |  |  |  |  |9 |  |                     Figure 6: Area 1's MOSPF database.             Networks and routers are represented by vertices.             An edge of cost X connects Vertex A to Vertex B iff             the intersection of Column A and Row B is marked             with an X. In addition, RT1, RT2 and N3 are labelled             with multicast group A, RT1 is labelled with multicast             group B, and both RT3 and RT4 are labelled as             wild-card multicast receivers.Moy                                                            [Page 23]RFC 1584              Multicast Extensions to OSPF            March 1994                                 **FROM**                           |RT|RT|RT|RT|RT|RT|RT                           |3 |4 |5 |6 |7 |10|11|                        ------------------------                        RT3|  |  |  |6 |  |  |  |                        RT4|  |  |8 |  |  |  |  |                        RT5|  |8 |  |6 |6 |  |  |                        RT6|8 |  |7 |  |  |5 |  |                        RT7|  |  |6 |  |  |  |  |                    *  RT10|  |  |  |7 |  |  |2 |                    *  RT11|  |  |  |  |  |3 |  |                    T    N1|4 |4 |  |  |  |  |  |                    O  

⌨️ 快捷键说明

复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?