Subject: Re: RSVP over network using IP-PIM multicast routing - Path msg received on more than 1 interface

From: Bob Braden <[email-masked]>
Date: Mon, 1 May 2000 23:19:30 GMT

*> 
  *> Hello,
  *> 
  *> I have the following question regarding RSVP over a network using
  *> PIM-SM routing (multicast scenario).  The problem is experienced before
  *> multicast routing switches to shortest path tree algorithm. In that

The RSVP logic for shared trees was not fully worked out in detail.
The primary thinking about it, by Daniel Zappala, appears in his
RSRR v.2 spec (An expired Internet Draft from Nov 98 that is
however available on the ISI RSVP Web page http://www.isi.edu/rsvp/pub.html).

  *> case all traffic is being forwarded to the randezvous point, and then
  *> it may be routed back towards the sender (see the scenario below).
  *> 
  *> For a scenario:
  *> Sender ------->Router1 --------->Router 2- Randezvous Point 
  *> -------->Destination1
  *>                            ----
  *>                               ---> Destination2
  *> 

Unfortunately your picture was broken as displayed as ASCII text
in my mailer. Is the following picture correct?

	Sender ----> Router1 -------> Router2 = RP
                        |                 |
                        V                 V
                     Destination1      Destination2

Pardon me if I write something stupid, but I think that the original
data packets from Sender to RP are encapsulated and sent unicast.  If
this is true, there are two distinct sessions:

	Unicast: Sender ----> Router1 -------> Router2 = RP

and

	Multicast: 

	          Router2 = RP -------> Router1
                        |                 |
                        V                 V
                     Destination1      Destination2

These are handled independently by RSVP, and this should resolve all
the conflicts. Note that the RP must merge the requests from the
two multicast destinations, map it into the unicast session for
return to the sender.

I believe it is  also possible for the initial sender-->RP flow
to be unencapsulated but use a (one-branch) source tree.  This
possibility is noted in Zappala's Internet Draft, under the
description of "unidirectional shared" tree type.  Perhaps the
tree type needs to be logically concatenated with the destination
address in forming the session, to still divide the flow into
two distinct subflows as above.

I will be interested to know whether others think this makes sense.

Bob Braden

  *> 
  *> Scenario in summary:
  *> - sender sending to a multicast group (Destination1 and Destination2 joined 
  *> that group),
  *> - second router - Router2 is a randezvous point
  *> 
  *> Routing of Path messages using PIM-SM routing (before shortest-tree is 
  *> being used):
  *> - Path message from sender is received on Router2
  *> - Router2 forwards the message to Router2-Randezvous Point
  *> - Router2-Randezvous Point forwards the traffic to Destination1 and Router1
  *> - Router1 forwards the traffic to Destination2
  *> 
  *> Problems:
  *> 1. Router1 receives Path message from 2 hops
  *>               - Sender
  *>               - Router2 - Randezvous Point
  *> 
  *> RFC 2209 it is assumed that Path message can be received only on 1
  *> incoming interface. If there are 2 incoming interfaces, one of them is
  *> considered not to be used for routing of Resv messages.
  *> 
  *> 2. Even if we dropped the assumption that Path message can be received
  *> on 1 incoming interface, and considered both states to be forwarding,
  *> what about forwarding of Resv messages?
  *> 
  *> RFC 2205 states that RSVP messages are never forwarded on the same
  *> interface they arrived.  But when Router1 receives Resv message ,
  *> according to the Path states on Router1, the message should be
  *> forwarded to Router2 and Destination2.  Since Resv message was received
  *> from Router2, the message will not be forwarded to Router2.  This will,
  *> however, imply that no reservation will be made on the
  *> Router1---Router2 link in the direction Router2->Router1. But the
  *> traffic routed by PIM-SM also flows from Router2->Router1.
  *> 
  *> Does anybody know how the above case is handled? Can you please point me to 
  *> the appropriate documentation?
  *> 
  *> If further clarification is needed, please ask.
  *> 
  *> Thanks you very much for your time.
  *> 
  *> Dana
  *> 
  *> 
  *> 
  *> ************************************
  *> Dana Znamova
  *> OPNET Applications Engineer
  *> OPNET Technologies, Inc.
  *> www.mil3.com
  *> 202-364-4700
  *> ************************************
  *> 
  *>

---

From: Dana Znamova <[email-masked]>
Date: Mon, 01 May 2000 20:19:41 -0400

Hello,

I am sorry my original picture got broken.
This is how it was originally (I simplified it to make it more clear):

1. Sender->Router1->Router2->Destination

2. Router1->Destination1

Router2 is a randezvous point.

The scenario below is for the case when short-path tree is not yet used.

That means that the traffic will flow with unicast destination address
to the randezvous point (Router2), and then router2 will send it to
Destination, Destination2, and Router1.
Router1 will then forward the packet to Destination1.

Problem:
Path messages will take the same path as data packets. That means
that before Path message gets to Destination1, it will get to the 
randezvous point,
and then it will be forwarded "back" to Router1 and Destination2.

This implies that Router1 will receive the message twice.
1. on the interface from Sender
2. on the interface from Router2

Routing will know how to forward it, but the question is:
HOW MANY PATH STATES SHOULD THE PATH MESSAGE CREATE?
One or two?

And then, how should the reservation be made?
Should it account for the packets being sent "backwards in the direction
towards the sender?

Moreover, RFC 2209 "Algorithmic Processing of RSVP messages"
assumes that RSVP Path message can be received on only one
interface (state created based on this message is then considered
to be forwarding. Path message received on an interface not expected
by routing will create a Path state, but that state will not be used for
forwarding of Path messages).

Please, be so kind, and let me know how to approach the problem above.
I will also read suggested draft RFCs to find out whether they discuss the
probelm.

Your help is greatly appreciated.

Thanks.

Dana

>   *> Thanks you very much for your time.

************************************
Dana Znamova
OPNET Applications Engineer
OPNET Technologies, Inc.
www.mil3.com
202-364-4700
************************************