Extended RSVP-TE for Multicast LSP Tunnels
draft-yasukawa-mpls-rsvp-multicast-01

Document Type Expired Internet-Draft (individual)
Author Seisho Yasukawa 
Last updated 2002-11-04
Stream (None)
Intended RFC status (None)
Formats
Expired & archived
pdf htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state Expired
Telechat date
Responsible AD (None)
Send notices to (None)

This Internet-Draft is no longer active. A copy of the expired Internet-Draft can be found at
https://www.ietf.org/archive/id/draft-yasukawa-mpls-rsvp-multicast-01.txt

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

Authors

Seisho Yasukawa (yasukawa.seisho@lab.ntt.co.jp)

(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)