@techreport{yasukawa-mpls-rsvp-multicast-01, number = {draft-yasukawa-mpls-rsvp-multicast-01}, type = {Internet-Draft}, institution = {Internet Engineering Task Force}, publisher = {Internet Engineering Task Force}, note = {Work in Progress}, url = {https://datatracker.ietf.org/doc/draft-yasukawa-mpls-rsvp-multicast/01/}, author = {Seisho Yasukawa}, title = {{Extended RSVP-TE for Multicast LSP Tunnels}}, pagetotal = 46, year = 2002, month = nov, day = 4, abstract = {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).}, }