The MPLS WG Archive

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

Seisho Yasukawa wrote:
> 
> 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.

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

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

point-to-multipoint is simply a subset of IP multicast, where there is 
only one sender.

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

Transit nodes never have to know anything about the data-plane payload.

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.

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

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

Tunnel ID is not a globally unique value.

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.

As for topology changes, that's why the concept of a multicast group was 
invented in the first place.  It's a way to uniquely identify the entire 
set of senders, receivers, and links.  By eliminating it, you now have 
to replace it with something else that does the same thing or you make 
your new protocol needlessly complicated.

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

All of the work necessary to define and maintain your topology is 
already defined for all of the major multicast routing protocols.  There 
is no need to redefine it in yet another protocol.

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

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.

This is no different from how TE is being used in the unicast case. 
People are creating LSPs that connect from one edge of their network to 
the other edge.  The addresses used here do not have to be global 
addresses, since the LSP never leaves the private address space.

Similarly, your choice of multicast group addresses don't have to be 
global addresses, since your group won't ever extend beyond your own 
network.

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

I still think you can accomplish all of your goals using an existing 
multicast routing protocol and an unmodified RSVP-TE protocol.

-- David