The MPLS WG Archive

[David Charlap <david.charlap@marconi.com>]

Seisho Yasukawa wrote:
> David Charlap wrote:
>>
>> You mean the lack of explicit routes.  TE is a very broad and vague term.
> 
> Yes, I mean that we must add and define the explicit routes function to 
> existing RSVP-TE to enable multicast traffic engineering.

I agree, that a definition for multicast EROs would be a good idea, 
although I think such an object will end up consuming a lot of 
bandwidth. A multicast tree, for a non-trivial network will consume 
hundreds, if not thousands of bytes.  Considering that existing RSVP 
messages are on the order of 100-200 bytes, this is not something we can 
just gloss over.

> We also want the scheme to rerouting the multicast traffic when some error occurs in the network.
> Some multicast routing mechanism may find these error and find another available route finally.
> But we think we need more reliable and faster rerouting mechanism in multicast environment.

This is where I think you're reinventing the wheel.  If there is a 
problem with existing multicast routing protocols, then I think 
everyone's effort is best spent trying to improve the routing protocols.

I really don't like the idea of adding routing functionality into a 
signaling protocol.  It makes everything much more complicated than it 
has to be.

> We think that specifying an IP mulitcast group address as the tunnel 
> endpoint has completely different meaning compared with unicast case.
> The unicast IP address is attached to physical IF or node and indicates 
> its physical location in the network.
> Therefore, we can specify the tunnel endpoint by this address.
> But multicast group address cannot specify the physical location. As a 
> result, we can not specify the tunnel endpoint by this address.

The session address does more than identify an endpoint.  It also serves 
as a key to group together multiple connections within a router.  When 
you eliminate the field from the SESSION object, you end up deleting 
that key.  The tunnel ID and sender address alone are not sufficient to 
completely specify a multicast session.

I realize that you're only interested in point-to-multipoint, but I 
don't think it's right to declare that this is the one and only form of 
multicast that MPLS will be allowed to support.

> In addition to this problem, it is not convenient to use single IP 
> multicast address because we cannot accommodate
> several IP multicast group traffic and non-IP traffic in a single 
> multicast LSP tunnel.

This doesn't follow.  There is no reason why an IP destination address 
in RSVP must necessarily imply an IP payload in the LSP.  There are many 
different mechanisms where you can specify non-IP payload, even though 
the endpoint address is IP.

>> Note also that you will need _some_ mechanism for defining the 
>> endpoints of a multicast LSP.  If you don't define an IP multicast 
>> group and have your egress routers all join that group, then you'll 
>> have to re-invent the wheel by replicating what existing multicast 
>> routing protocols already do.
> 
> We define the endpoint of a multicast LSP by TERO and TRRO.

Which completely redefines a key part of the RSVP protocol.  The SESSION 
is supposed to define the endpoints.  The ERO is supposed to be used to 
override the routing table, where that is necessary.

With your draft, you change the semantics of RSVP so much that it isn't 
even the same protocol anymore.  Your semantics are much closer to 
CR-LDP than they are to RSVP.

>> There's no big deal if you want to define your own private multicast 
>> groups, for the purpose of establishing TE across your own routing 
>> core.  Once the multicast LSPs are in place, you can then transit any 
>> traffic you want across it.
>>
>> Remember, you're not interested in setting up LSPs that run from a 
>> server to all of the millions of hosts receiving from that server. 
>> You're interested in setting up LSPs to efficiently transit multicast 
>> traffic to the edges of your network.  This is especially true if 
>> you're talking about non-IP traffic.
> 
> As mentioned above, we are not interested in shortest path tree that is 
> calculated by conventinal IP multicast routing protocol.
> Although we define the private multicast group, we cannot still control 
> tree topology and multicast traffic across it.

This is no different from unicast RSVP, where the ERO object overrides 
the local routing table.  We don't eliminate the endpoint address from 
the SESSION object just because we're not using the routing table.

In a unicast environment, the routing protocols continue to run as 
always.  The ingress nodes use the routing table in order to detect 
tunnel endpoints, and to construct explicit routes to those endpoints.

Multicast behavior can be similar.  There is no reason why RSVP has to 
use the multicast routing table.  The ingress nodes can use the 
multicast routing table to detect endpoints (where the tree leaves the 
MPLS cloud), and build a TERO based on those endpoints and the unicast 
routing table.  No changes to RSVP, other than the TERO object are 
necessary for this.

-- David