draft-ietf-mboned-imrp-some-issues-02.txt   draft-ietf-mboned-imrp-some-issues-03.txt 
MBONE Deployment Working Group David Meyer MBONE Deployment Working Group David Meyer
Internet Draft University of Oregon Internet Draft University of Oregon
November 1997
Expiration Date: December 1997 June 1997
Some Issues for an Inter-domain Multicast Routing Protocol Some Issues for an Inter-domain Multicast Routing Protocol
draft-ietf-mboned-imrp-some-issues-02.txt draft-ietf-mboned-imrp-some-issues-03.txt
1. Status of this Memo 1. Status Of This Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.'' material or to cite them other than as ``work in progress.''
skipping to change at page 2, line 30 skipping to change at page 2, line 30
4. Forwarding State Distribution 4. Forwarding State Distribution
The objective of a multicast forwarding state distribution mechanism The objective of a multicast forwarding state distribution mechanism
is to ensure that multicast traffic is efficiently distributed to is to ensure that multicast traffic is efficiently distributed to
those parts of the topology where there are receivers. Dense and those parts of the topology where there are receivers. Dense and
sparse mode protocols will accept differing overheads based on design sparse mode protocols will accept differing overheads based on design
tradeoffs. In the dense mode case, the data-driven nature state tradeoffs. In the dense mode case, the data-driven nature state
distribution has disadvantage that data is periodically distributed distribution has disadvantage that data is periodically distributed
to branches of the distribution tree which don't have receivers to branches of the distribution tree which don't have receivers
("Broadcast and Prune" behavior). It seems unlikely that this ("Flood and Prune" behavior). It seems unlikely that this mechanism
mechanism will be scalable to Internet-wide case. will be scalable to Internet-wide case.
On the other hand, sparse mode protocols use receiver-initiated, On the other hand, sparse mode protocols use receiver-initiated,
explicit joins to establish a forwarding path along a shared explicit joins to establish a forwarding path along a shared
distribution tree. While the on-demand nature of sparse mode distribution tree. While the on-demand nature of sparse mode
protocols have favorable properties with respect to distribution of protocols have favorable properties with respect to distribution of
forwarding state, it also has the possible disadvantage of creating forwarding state, it also has the possible disadvantage of creating
dependencies on shared resources (again, see the section on "Third- dependencies on shared resources (again, see the section on "Third-
Party Resource Dependencies" below). Party Resource Dependencies" below).
5. Forwarding State Maintenance 5. Forwarding State Maintenance
skipping to change at page 3, line 28 skipping to change at page 3, line 28
multicast to scale to Internet sizes. Thus it seems likely that multicast to scale to Internet sizes. Thus it seems likely that
Inter-domain multicast routing protocols will have to do less Inter-domain multicast routing protocols will have to do less
forwarding state maintenance, and hence be less aggressive in forwarding state maintenance, and hence be less aggressive in
reshaping distribution trees. Note that this reshaping is related to reshaping distribution trees. Note that this reshaping is related to
what has been termed "routing flux" (again, see [LABOV97]), since the what has been termed "routing flux" (again, see [LABOV97]), since the
routing traffic does not directly affect path selection. Rather, the routing traffic does not directly affect path selection. Rather, the
primary effect is to require significant processing resources in a primary effect is to require significant processing resources in a
border router. Finally, note that unlike the unicast case, we do not border router. Finally, note that unlike the unicast case, we do not
have good data characterizing this effect for multicast routers. have good data characterizing this effect for multicast routers.
5.1. Data Driven Forwarding State Creation 5.1. Bursty Source Problem
Another issue with broadcast and prune protocols is that forwarding
state is created in a data-driven manner.
5.2. Bursty Source Problem
When a source's inter-burst period is longer than the router state When a source's inter-burst period is longer than the router state
timeout period, some or all of a source's packets can be lost. This timeout period, some or all of a source's packets can be lost. This
effect has been termed the "Bursty Source Problem" [ESTRIN97]. The effect has been termed the "Bursty Source Problem" [ESTRIN97]. The
current set of multicast routing protocols attempt, where possible, current set of multicast routing protocols attempt, where possible,
to avoid this problem (i.e., maximize response to bursty sources). to avoid this problem (i.e., maximize response to bursty sources).
6. Mixed Control 6. Mixed Control
Mixing control of topology discovery and distribution tree Mixing control of topology discovery and distribution tree
skipping to change at page 6, line 26 skipping to change at page 6, line 20
be exacerbated if the RP/Core space is global; if a router is be exacerbated if the RP/Core space is global; if a router is
registering to a RP/Core that is not in the local domain (say, registering to a RP/Core that is not in the local domain (say,
fielded by the site's direct provider), then the routing domain is fielded by the site's direct provider), then the routing domain is
flat. flat.
12. Multicast Internal Gateway Protocol (MIGP) Independence 12. Multicast Internal Gateway Protocol (MIGP) Independence
A shared tree, explicit join protocol inter-domain routing protocol A shared tree, explicit join protocol inter-domain routing protocol
may require modification to a leaf domain's internal multicast may require modification to a leaf domain's internal multicast
routing mechanism. The problem arises when a domain is running a routing mechanism. The problem arises when a domain is running a
"broadcast and prune" protocol such as DVMRP or PIM-DM internally "flood and prune" protocol such as DVMRP or PIM-DM internally while
while participating in a shared tree inter-domain protocol. In this participating in a shared tree inter-domain protocol. In this case,
case, there can be areas of the (internal) topology that has there can be areas of the (internal) topology that has receivers but
receivers but will not receive inter-domain traffic. will not receive inter-domain traffic.
[THALER96] describes interoperability rules to alleviate this [THALER96] describes interoperability rules to alleviate this
problem. Consider the case where a border router has interfaces in an problem. Consider the case where a border router has interfaces in an
inter-domain shared tree region and a DVMRP region. The rules inter-domain shared tree region and a DVMRP region. The rules
covering this case state that either the DVMRP region must implement covering this case state that either the DVMRP region must implement
Region Wide Reports [HDVMRP], or the DVMRP component of the border Region Wide Reports [HDVMRP], or the DVMRP component of the border
router must be a wildcard receiver for externally reached sources, router must be a wildcard receiver for externally reached sources,
while the shared tree component is a wildcard receiver for internally while the shared tree component is a wildcard receiver for internally
reached sources. Alternatively, many current implementations use a reached sources. Alternatively, many current implementations use a
"receiver-is-sender" approach (which depends for the most part on "receiver-is-sender" approach (which depends for the most part on
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/