Subject: I-D ACTION:draft-yasukawa-mpls-rsvp-multicast-00.txt

From: [email-masked]
Date: Thu, 27 Jun 2002 06:38:41 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Extended RSVP-TE for Multicast LSP Tunnels
	Author(s)	: S. Yasukawa et al.
	Filename	: draft-yasukawa-mpls-rsvp-multicast-00.txt
	Pages		: 39
	Date		: 26-Jun-02
	
Multicast technology will become increasingly important with the
dissemination of new applications such as contents delivery services
and video conferences, which require much more bandwidth and stricter
QoS than conventional applications. From the service providers'
perspective, traffic engineering (TE) functions will be needed to
handle the large amount of multicast traffic.
This document defines some protocol extensions to the existing RSVP-
TE[1] in order to establish a multicast label switched path (LSP).
The use of label switching routers (LSRs) with these protocol
extensions defined in this document allows service providers to offer
unicast and multicast multiprotocol label switching (MPLS) services
in the same service network.
This protocol assumes a variable LSP topology, e.g., point-to-
multipoint, multipoint-to-multipoint, topologies. This document
describes how to establish point-to-multipoint and multipoint-to-
multipoint LSPs as the most basic multicast topology. It defines two
ways of constructing a point-to-multipoint LSP: sender-initiated LSP
setup and leaf-initiated LSP setup. Each method has an LSP
modification function in order to adapt to dynamic changes in the LSP
tree topology.
This MPLS architecture[10] is very flexible and can be expanded to
carry protocols other than IP multicasting, e.g., Ethernet, PPP, and
SONET/SDH, but this document only defines IP multicasting (IPv4 and
IPv6) as a forwarding equivalence class object (FEC).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-yasukawa-mpls-rsvp-multicast-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-yasukawa-mpls-rsvp-multicast-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-yasukawa-mpls-rsvp-multicast-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: David Charlap <[email-masked]>
Date: Thu, 27 Jun 2002 13:36:12 -0400

> 	Filename	: draft-yasukawa-mpls-rsvp-multicast-00.txt

Since Seisho Yasukawa has explicitly asked for comments.....

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.

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.

When Resv messages return, the FLOWSPEC values are merged according to 
the rules for classical RSVP (RFC 2205 and related documents).  Incoming 
LABEL objects are installed on the next-hop interfaces.  One label is 
generated to send upstream - using the merged FLOWSPEC object.

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.

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