Engineering Paths for Multicast Traffic using MPLS
draft-leecy-multicast-te-01
Document | Type | Expired Internet-Draft (individual) | |
---|---|---|---|
Last updated | 1999-11-11 | ||
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) |
https://www.ietf.org/archive/id/draft-leecy-multicast-te-01.txt
Abstract
This document describes a solution to engineer paths for IP multicast traffic in a network, by directing the control messages to setup multicast trees on engineered paths. This enables the network operator to have control over the topology of multicast trees. This proposal partitions the multicast traffic engineering problem such that multicast routing protocols do not have to be modified to allocate resources for multicast traffic nor do resource allocation protocols such as RSVP or CR-LDP have to be able to setup forwarding states (in this case labels) like multicast routing protocols. Resources are allocated on the same trip that paths are selected and setup. This prevent the problem of data being forwarded on branches of the tree where resources have not being allocated yet. An important aspect of this proposal is that it enables multicast paths to be engineered in an aggregatable manner, allowing this solution to scale in the backbone.
Authors
Ken Carlberg
(carlberg@g11.org.uk)
Loa Andersson
(loa@pi.se)
Cheng-Yin Lee
(Cheng-Yin.Lee@alcatel.com)
Bora Akyol
(akyol@pluris.com)
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)