The MPLS WG Archive

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

Dear David

>>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.
>
>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.

We think TE becomes more important when considering multicast application.

When considering multicast TE, we want to engineer (control) multicast tree 
topology.
But, as you know, most of conventional IP multicast routing protocol only 
establish shortest path
multicast tree because these protocol utlized RPF mechanism when 
constructing multicast route.
Therefore, we need TERO (Tree Explicit Route Object) that can control 
multicast LSP topology.

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.
Most of multicast tree has tree topology and the error near the root node 
cause tragic effect on
multicast traffic transmission.
To enable first and reliable recovery, we think it is better to devide path 
setup and multicast routing
mechanism seperatory.
Therefore, we design multicast MPLS protocol that only use unicast routing 
information and propose
TERO to control the tree topology and Graft/Prune mechanism to 
setup/release partial multicast
tree.


>If you think you need to define a multicast ERO, you can do that without 
>changing the rest of the protocol.

We define a TERO with necessary modification in our draft.

>In unicast scenarios, there is nothing requiring the traffic to be IP. As 
>a matter of fact, there are two different explicit mechanisms for non-IP 
>traffic.  One is to specify the Ethertype for the payload in the 
>LABEL_REQUEST object, and the other is to signal an IP LSP, and use an 
>extra label on the stack to identify the protocol (the Martini draft).
>
>Yes, you need to specify an IP address for the tunnel endpoint, but you 
>need to do that for unicast LSPs as well.

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.
This is a fundamental problem caused by the definition of SESSION object in 
conventional RSVP-TE protocol.
Therefore, we newly redefine MULTICAST SESSION object in our draft.

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.


>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.

>   Multicast is difficult enough with established protocols (IGMP, DVMRP, 
> PIM-DM and PIM-SM).  Inventing yet another routing protocol, and making 
> it part of RSVP (which is already enormously complex) is something I 
> would want to avoid at all costs.

We also think that IP multicast routing protocol is difficult to engineer 
and has problem in its scalablity.
And we think it is not good choice to combine the IP multicast routing 
protocol and conventional RSVP-TE.
Therefore, we proposed the combination of extended RSVP-TE protocol that 
has multicast capability and
conventional unicast routing protocol.

>And note that you are forcing your multicast to be only p-to-mp.  You are 
>not permitting IP multicast (wich is mp-to-mp) to be used.  Which means 
>you end up with less funcationality than there was before.

We propose the mp-to-mp LSP setup mechanism in our draft.
Please see, section 7.


>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.
We think it is much easier to control traffic by path layer compared with 
routing layer.
MPLS is attractive because it can control traffic by path (LSP) independent 
to routing protocol when considering TE.
Therefore, we think multicast MPLS protocol must support not only multicast 
LSP that is established by multicast routing protocol
but also multicast LSP that is established by TERO.

Best regards,

Seisho Yasukawa