IDPR multicast
Martha Steenstrup <msteenst@bbn.com> Tue, 15 December 1992 16:23 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04138; 15 Dec 92 11:23 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04128; 15 Dec 92 11:23 EST
Received: from HYPATIA.BBN.COM by CNRI.Reston.VA.US id aa10615; 15 Dec 92 11:25 EST
Received: from pizza by PIZZA.BBN.COM id aa06253; 15 Dec 92 10:22 EST
To: swb@cornell.edu
cc: idpr-wg@bbn.com
Subject: IDPR multicast
Date: Tue, 15 Dec 1992 11:19:23 -0500
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Martha Steenstrup <msteenst@bbn.com>
Message-ID: <9212151125.aa10615@CNRI.Reston.VA.US>
Hi Scott, Thanks for your comments on IDPR multicast pertaining to my rather broad statement: "Intra-domain multicast, when available, will be used in conjunction with IDPR multicast." >> I suspect you have thought of all >>this already. No, on the contrary. However, I'm afraid that I don't understand most of the issues you have raised, and so I have included questions and comments on your text in the hope that you will help me out. >>I believe you have the same problem with intra-domain multicast that you >>have with intra-domain unicast -- that unless a domain's internal routers >>understand (and are capable of understanding) the inter-domain routing, >>then they cannot satisfy the requirements of inter-domain routing. This is >>what led to encapsulation of IDPR packets to get them across domains, as I >>recall. Yes, that's right. We didn't want to have to force intra-domain routers to have to maintain inter-domain routing and forwarding information nor to have to understand how to parse IDPR-specific information contained in IDPR messages. >>In the multicast case, a domain either has to learn how a particular source >>is reaching it or it has to make a wild guess. If a domain's routers make >>the wrong guess then the multicast packets might not be delivered correctly >>(if at all). I'm confused about this "guessing". IDPR multicast paths are set up among domains in the same manner as IDPR unicast paths. During unicast path setup, the policy gateway that receives a setup message at the entry to a domain, learns of the exit virtual gateway through information contained within the setup message. The multicast case is analogous, except that multiple path setup messages may be used to set up the multicast tree. However, the entry policy gateway still discovers the exit virtual gateway(s) through information contained in the path setup message(s). Hence, an entry policy gateway is told which exit virtual gateway(s) to use during path setup. When transmitting IDPR multicast traffic to entities within a domain, whether they are the ultimate destinations or policy gateways leading to other domains, entry policy gateways should take advantage of intra-domain multicast transport (if available) in order to reduce resource use within their domains. As part of multicast path setup, the entry policy gateway may wish to form a multicast group consisting of its selected policy gateways within the designated exit virtual gateways. Such a multicast group need only persist for the life of the IDPR multicast tree. Moreover, the multicast distribution of information across the domain is directed, i.e. it always flows from the entry policy gateway to the selected exit policy gateways. Once the group's address is established, the entry policy gateway, upon receiving an IDPR multicast data message on the given path encapsulates the message using the exit policy gateways' multicast group address as the destination. (It would be beneficial if the intra-domain multicast procedure were able to handle dynamic creation and destruction of multicast groups and their addresses.) Handling multicast destination hosts within a domain should work as follows. Each policy gateway within a domain will need to learn how to forward messages to well-known multicast groups represented by hosts in its domain. It uses intra-domain routing and multicast information to do so. Provided the source host's destination address is a multicast address known throughout all domains, then delivering data messages from the source host to members of the given multicast group located with the given domain is straightforward. The entry policy gateway decapsulates the IDPR data message so that the source's original message is exposed. Then the message is forwarded within the domain, according to the multicast address. (In the future, we may need to deal with source/destination address translation for both unicast and multicast IDPR, but for now we assume that the source's original message is forwardable in each destination domain.) >> Not only might they not be delivered to (all) group >>participants inside the domain, they won't necessarily be delivered to >>other domains correctly either. How come? I must be really dense. I don't understand the problem. >>Suppose we try to inject knowledge into the domain. The minimum we need to >>tell the internal routers is which PG a particular source/group is supposed >>to arrive on (I'm assuming the inter-domain tree setup informs a domain's >>PGs which one will be the entry point for a source/group's packets). I >>don't know how you would do this. I don't understand why you need to inject information into the domain for the IDPR multicast case. We don't need to do it in the IDPR unicast case. >> If we do not inject knowledge of inter-domain routing into the domain, then >>the domain's routers will have to assume, say, Reverse Path Forwarding in >>the outer world (in theory this is what MOSPF does). In that case >>multicast packets must *appear* to arrive at the PG which would be correct >>if RPF *was* in force outside. This is most easily done by encapsulating >>and sending the packets from the entry PG to the "correct" PG, which can >>inject it into the domain. (This idea was originally from John Moy.) Why do the domain's routers need to know anything about inter-domain routing? The forwarding information is presented to the entry policy gateway in the path setup message, and it decides how messages should propagate across a domain. >>For packets which are going to transit the domain, you might as well >>encapsulate (a copy of) them to send to the far PG. We do encapsulation for transit, but for domains supporting multicast, we needn't make a separate copy of the message for each exit policy gateway. Instead, the entry policy gateway can encapsulate a single message within an intra-domain multicast packet, where the destination policy gateways form a multicast group. >>I don't know the status of aggregation/abstraction in IDPR, but this will >>have a serious effect on multicast routing, especially if a particular >>multicast source hears about different levels of aggregate via different >>paths. I don't think I understand your question clearly enough. In IDPR, the way to consolidate information is through superdomains. Our implementation does not yet handle superdomains, because we can't address them correctly with the current IDPR packet format. Perhaps I haven't thought about this carefully enough, but I am having trouble understanding the problems of multicast in the presence of superdomains. Please elaborate a bit; I want to know what I'm missing. >>Clearly you need teardown messages to be sent in both directions if a link >>between domains which is part of a multicast tree is lost. Yes, but it's a little more complicated than that. Provided the link cannot be "healed" by local path repair, teardowns occur as follows. The policy gateway at the destination end of the link sends a teardown message down the multicast path toward all destination domains in that subtree. In this case, all resources associated with the path in this subtree will be released. The policy gateway at the source end of the link sends a teardown message to the source, but this teardown message may not necessarily release resources. For example, if the domain on the source side of the link failure contains hosts that are members of the given multicast group, that domain should remain in the multicast tree. In this case, the teardown message alerts all "upstream" policy gateways in the multicast tree that the given subtree is no longer there. The teardown toward the source only releases resources at a given domain if the domain contains no host members of the multicast group, and if there are no active parts of the multicast tree below it. Scott, I want to understand your concerns. And so far I haven't. Please enlighten me. Thanks, m
- IDPR multicast Martha Steenstrup
- IDPR multicast Martha Steenstrup
- IDPR multicast Martha Steenstrup