IDPR multicast

[Martha Steenstrup <[e-mail]>]

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