mLDP In-Band Signaling with Wildcards
draft-wijnands-mpls-mldp-in-band-wildcard-encoding-03
Document | Type | Replaced Internet-Draft (mpls WG) | |
---|---|---|---|
Last updated | 2014-01-08 | ||
Replaced by | draft-ietf-mpls-mldp-in-band-wildcard-encoding | ||
Stream | IETF | ||
Intended RFC status | Proposed Standard | ||
Formats |
Expired & archived
plain text
pdf
html
|
||
Stream | WG state | Adopted by a WG | |
Document shepherd | Loa Andersson | ||
IESG | IESG state | Replaced by draft-ietf-mpls-mldp-in-band-wildcard-encoding | |
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) |
https://www.ietf.org/archive/id/draft-wijnands-mpls-mldp-in-band-wildcard-encoding-03.txt
Abstract
There are scenarios in which an IP multicast tree traverses an MPLS domain. In these scenarios, it can be desirable to convert the IP multicast tree "seamlessly" to an MPLS multipoint label switched path (MP-LSP) when it enters the MPLS domain, and then to convert it back to an IP multicast tree when it exits the MPLS domain. Previous documents specify procedures that allow certain kinds of IP multicast trees (either "Source-Specific Multicast" trees or "Bidirectional Multicast" trees) to be attached to an MPLS Multipoint Label Switched Path (MP-LSP). However, the previous documents do not specify procedures for attaching IP "Any Source Multicast" trees to MP-LSPs, nor do they specify procedures for aggregating multiple IP multicast trees onto a single MP-LSP. This document specifies the procedures to support these functions. It does so by defining "wildcard" encodings that make it possible to specify, when setting up an MP- LSP, that a set of IP multicast trees, or a shared IP multicast tree, should be attached to that MP-LSP. Support for non-bidirectional IP "Any Source Multicast" trees is subject to certain applicability restrictions that are discussed in this document.
Authors
IJsbrand Wijnands
([email protected])
Eric Rosen
([email protected])
[email protected]
([email protected])
Uwe Joorde
([email protected])
Jeff Tantsura
([email protected])
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)