rfc1584.txt
来自「著名的RFC文档,其中有一些文档是已经翻译成中文的的.」· 文本 代码 · 共 1,306 行 · 第 1/5 页
TXT
1,306 行
o RT3 (N4, origin) / \ 1/ \8 / \ N3 (Mb) o o RT6 / \ 0/ \7 / \ RT2 (Ma,Mb) o o RT10 / \ 3/ \1 / \ N8 o o N6 (Ma) / 0/ / RT11 o / 1/ / N9 o / 0/ / RT9 (Ma) o Figure 3: Sample datagram's shortest-path tree, source N4, destination Group A The router's (call it Router RTX) position in the datagram's pruned shortest-path tree consists of 1) RTX's parent in the tree (this will be the forwarding cache entry's upstream node) and 2) the list of RTX's interfaces that lead to downstream routers/transit networks that have been labelled with the datagram's destination (these will be added to the forwarding cache entry as downstream interfaces). Note that after calculating the datagram's shortest path tree, a router may find that it is itself not on the tree. This would be indicated by a forwarding cache entry having no upstream node or an empty list of downstream interfaces. As an example of a router describing its position on the datagram's shortest-path tree, consider Router RT10 in Figure 3. Router RT10's upstream node for the datagram is Router RT6, and there are two downstream interfaces: oneMoy [Page 15] RFC 1584 Multicast Extensions to OSPF March 1994 connecting to Network N6 and the other connecting to Network N8. 2.3.3. Support for Non-broadcast networks When forwarding multicast datagrams over non-broadcast networks, the datagram cannot be sent as a link-level multicast (since neither link-level multicast nor broadcast are supported on these networks), but must instead be forwarded separately to specific neighbors. To facilitate this, forwarding cache entries can also contain downstream neighbors as well as downstream interfaces. The IGMP protocol is not defined over non-broadcast networks. For this reason, there cannot be group members directly attached to non-broadcast networks, nor do non- broadcast networks ever appear in local group database entries. As an example, suppose that Network N3 in Figure 1 is an X.25 PDN. Consider Router RT3's forwarding cache entry for datagrams having source Network N4 and multicast destination Group B. In place of having the interface to Network N3 appear as the downstream interface in the matching forwarding cache entry, the neighboring routers RT1 and RT2 would instead appear as separate downstream neighbors. In addition, in this case there could not be a Group B member directly attached to Network N3. 2.3.4. Details concerning forwarding cache entries Each of the downstream interface/neighbors in the cache entry is labelled with a TTL value. This value indicates the number of hops a datagram forwarded out of the interface (or forwarded to the neighbor) would have to travel before encountering a router/transit network requesting the multicast destination. The reason that a hop count is associated with each downstream interface/neighbor is so that IP multicast's expanding ring search procedure can be more efficiently implemented. By expanding ring search is meant the following. Hosts can restrict the frowarding extent of the IP multicast datagrams that they send by appropriate setting of the TTL value in the datagram's IP header. Then, for example, to search for the nearest server the host can send multicasts first with TTL set to 1, then 2, etc. By attaching a hop count to each downstream interface/neighbor in the forwarding cache, datagrams will not be forwarded unless they will ultimately reach aMoy [Page 16] RFC 1584 Multicast Extensions to OSPF March 1994 multicast destination before their TTL expires[8]. This avoids wasting network bandwidth during an expanding ring search. As an example consider Router RT10's forwarding cache in Figure 3. Router RT10's cache entry has two downstream interfaces. The first, connecting to Network N6, is labelled as having a group member one hop away (Network N6). The second, which connects to Network N8, is labelled as having a group member two hops away (Router RT9). Both the datagram shortest path tree and the local group database may contribute downstream interfaces to the forwarding cache entries. As an example, if a router has a local group database entry of [Group G, NX], then a forwarding cache entry for Group G, regardless of destination, will list the router interface to Network NX as a downstream interface. Such a downstream interface will always be labelled with a TTL of 1. As an example of forwarding cache entries, again consider the Autonomous System pictured in Figure 1. Suppose Host H2 sends a multicast datagram to multicast group A. In that case, some routers will not even attempt to build a forwarding cache entry (e.g, router RT5) because they will never receive the multicast datagram in the first place. Other routers will receive the multicast datagram (since they are forwarded as link-level multicasts), but after building the pruned shortest path tree will notice that they themselves are not a part of the tree (routers RT1, RT4, RT7, RT8 and RT12). These latter routers will install an empty cache entry, indicating that they do not participate in the forwarding of the multicast datagram. A sample of the forwarding cache entries built by the other routers in the Autonomous System is pictured in Table 2. A MOSPF router must clear its entire forwarding cache when the Autonomous System's topology changes, because all the datagram shortest-path trees must be rebuilt. Likewise, when the location of a multicast group's membership changes (reflected by a change in group-membership-LSAs), all cache entries associated with the particular multicast destination group must be cleared. Other than these two cases, forwarding cache entries need not ever be deleted or otherwise modified; in particular, the forwarding cache entries do not have to be aged. However, forwarding cache entries can be freely deleted after some period of inactivity (i.e., garbage collected), if router memoryMoy [Page 17] RFC 1584 Multicast Extensions to OSPF March 1994 Router Upstream Downstream interfaces node (interface:hops) ___________________________________________ RT10 Router RT6 (N6:1), (N8:2) RT11 Net N8 (N9:1) RT3 Net N4 (N3:1), (RT6:3) RT6 Router RT3 (RT10:2) RT2 Net N3 (N2:1) Table 2: Sample forwarding cache entries, for source N4 and destination Group A. resources are in short supply.3. Inter-area multicasting Up to this point this memo has discussed multicast forwarding when the entire Autonomous System is a single OSPF area. The logic for when the multicast datagram's source and its destination group members belong to the same OSPF area is the same. This section explains the behavior of the MOSPF protocol when the datagram's source and (at least some of) its destination group members belong to different OSPF areas. This situation is called inter-area multicast. Inter-area multicast brings up the following issues, which are resolved in succeeding sections: o Are the group-membership-LSAs specific to a single area? And if they are, how is group membership information conveyed from one area to the next? o How are the datagram shortest-path trees built in the inter-area case, since complete information concerning the topology of the datagram source's neighborhood is not available to routers in other areas? o In an area border router, multiple datagram shortest-path trees are built, one for each attached area. How are these separate datagram shortest-path trees combined into a single forwarding cache entry? It should be noted in the following that the basic protocol mechanisms in the inter-area case are the same as for the intra-area case. Forwarding of multicasts is still defined by the contents ofMoy [Page 18] RFC 1584 Multicast Extensions to OSPF March 1994 the forwarding cache. The forwarding cache is still built from the same two components: the local group database and the datagram shortest-path trees. And while the calculation of the datagram shortest-path trees is different in the inter-area case (see Section 3.2), the local group database is built exactly the same as in the intra-area case (i.e., MOSPF's interface with IGMP remains unchanged in the presence of areas). Finally, the forwarding algorithm described in Section 11 is the same for both the intra-area and inter-area cases. The following discussion uses the area configuration pictured in Figure 4 as an example. This figure, taken from the OSPF specification, shows an Autonomous System split into three areas (Area 1, Area 2 and Area 3). A single backbone area has been configured (everything outside of the shading). Since the backbone area must be contiguous, a single virtual link has been configured between the area border routers RT10 and RT11. Additionally, an area address range has been configured in Router RT11 so that Networks N9-N11 and Host H1 will be reported as a single route outside of Area 3 (via summary-link-LSAs). 3.1. Extent of group-membership-LSAs Group-membership-LSAs are specific to a single OSPF area. This means that, just as with OSPF router-LSAs, network-LSAs and summary-link-LSAs, a group-membership-LSA is flooded throughout a single area only[9]. A router attached to multiple areas (i.e., an area border router) may end up originating several group-membership-LSAs concerning a single multicast destination, one for each attached area. However, as we will see below, the contents of these group-membership-LSAs will vary depending on their associated areas. Just as in OSPF, each MOSPF area has its own link state database. The MOSPF database is simply the OSPF link state database enhanced by the group-membership-LSAs. Consider again⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?