The MPLS WG Archive

[Seisho Yasukawa <yasukawa.seisho@lab.ntt.co.jp>]

Dear David

Thank you for your comment.

I agree that classical RSVP was designed around multicast and existing 
RSVP-TE can
cope with multicast in essesntial. But I still think existing RSVP-TE is 
not suitable and
some modifications are necessary to support multicast because its lack of 
TE function.

>In my opinion, this draft is not necessary.  It is based on the incorrect 
>assumption that RSVP-TE, as it is currently defined, does not have 
>supprort for multicast.
>
>Classical RSVP was designed around multicast, and RSVP-TE introduces 
>nothing to change this, even though it does not explicitly describe a 
>multicast implementation.

As mentioned above, I agree with your assumption to RSVP-TE basically.
But please note that our draft describe some modification and extensions 
to existing RSVP-TE in order to cope with
not only multicast application but also p-to-mp application.

>For a multicast LSP, one has only to specify a multicast group address in 
>the SESSION object (the tunnel endpoint address), and do not include an 
>EXPLICIT_ROUTE object.  Normal Path processing should propagate the Path 
>message to all next-hops in the multicast group, according to the 
>multicast table that already exists.

We think some modification is necessary to SESSION object definition when 
considering multicast session.

We think it is important to define multicast LSP tunnel independent to its 
accomodated traffic.
In this design, intermediate node along the LSP must not conscious of its 
accomodated traffic protocol.
And we want a p-to-mp LSP to accomodate both multiple IP multicast group 
traffic and non-IP traffic,
such as Ether traffic.

Therefore, it is not convenient to specify a multicast group address in 
the SESSION object.

To enable the identification and association of such multicast LSP 
tunnels, new MULTICAST_LSP_TUNNEL
session objects are defined in our proposal. Each session object carries 
the sender node address of a p-to-mp LSP
and its tunnel ID. The sender node address is more preferable than 
destination (leaf) node addresses to identify
a multicast LSP tunnel because frequent topological changes may occur and 
destination node addresses are not
stable in this tunnel.

Therefore, the SENDER_TEMPLATE (or FILTER_SPEC) object together with this 
SESSION object uniquely identify
a multicast LSP tunnel. To identify the leaf and topology of this 
multicast LSP tunnel, TREE_EXPLICIT_ROUTE object
and TREE_RECORD_ROUTE object are also defined.


>I am aware that RSVP-TE's definition of EXPLICIT_ROUTE and RECORD_ROUTE 
>does not accommodate multicast.  If there is some need to specify an 
>explicit multicast tree that differs from the multicast routing table, 
>then this might be required.
>
>Personally, I think attempting to traffic-engineer a multicast tree 
>beyond what existing multicast routing protocols already do is pointless. 
>Any automatic process for generating these trees will duplicate all of the 
>work that routing protocols already do.  Any manual process will be 
>unmanageable, since receivers may be continuously joining and leaving the 
>multicast group.

We think Traffic Engineering become more important when considering 
multicast application.
A multicast LSP has more complex topology and it affect network switching 
resource more drastically compared with unicast LSP.

And we think it is not enough to combine existing multicast routing 
protocol and RSVP-TE to enable mulitcast traffic engineering.
We think what existing multicast routing protocol do for 
traffic-engineering is completely weak.

For example, PIM-SM that is most widely used multicast protocol, I think, 
has three phases to establish muticast tree.
Phase 1: Encapsulation transmission to Randezvous Point (RP) + RP 
Multicast Tree distribution
Phase 2: Register Stop Process which switch over to (S,G) transmission 
from RP encapsulation transmission
Phase 3: Shortest Path multicast distribution (switch over from RP transmission)
This mechanism allows very frequent topological change into tree topology.

Therefore we think it is not realistic to make multicast LSP synchronized 
with L3 multicast routing protocol.
We can not control multicast traffic completely in this design.
Moreover, path-protection mechanism or rerouting mechanism are not 
supported in this design.

>Given the infeasability of a manually-configured multicast LSP, we're 
>back to automatic configuration.  RSVP, as it currently stands, is 
>sufficient in this situation.  It reads the existing multicast routing 
>table to determine the next-hops for a multicast group, and monitors the 
>routing table to add and remove next-hops as needed.  Rules for merging 
>FLOWSPEC objects are already in place.  Rules for merging labels are 
>self-evident.
>
>While it is true that current RSVP-TE implementations do not have support 
>for multicast LSPs, there is nothing in RFC 3209 that prohibits the use of 
>RSVP-TE for multicast situations.  Note that the only part of RSVP-TE that 
>is not multicast-friendly is the EXPLICIT_ROUTE object - ant this object 
>is optional in Path messages anyway.
>
>-- David

As you mentioned above, it is better to construct multicast LSP automatically.
We can use TERO for this purpose.
Some multicast tree calculation mechanism that is implemented in Network 
Mangement Sytem or Sender node calculate
TERO that represents suitable multicast tree and invoke this multicast 
MPLS protocol to setup multicast LSP tunnel.

And as mentioned in our draft, our scheme also target to support multicast 
LSP setup using multicast routing table information.

We are sevice provider and strongly need this p-to-mp LSP setup mechanism 
to enable Contents delivery service and p-to-mp
L2/MPLS service.

We are willing to modify our proposal to accelerate this discussion.
Please join this discussion and give us comments.

Seisho