draft-ietf-mpls-mldp-in-band-wildcard-encoding-03.txt   rfc7438.txt 
MPLS Working Group IJ. Wijnands, Ed. Internet Engineering Task Force (IETF) IJ. Wijnands, Ed.
Internet-Draft Cisco Systems, Inc. Request for Comments: 7438 Cisco Systems, Inc.
Updates: 6826,7246 (if approved) E. Rosen Updates: 6826, 7246 E. Rosen
Intended status: Standards Track Juniper Networks, Inc. Category: Standards Track Juniper Networks, Inc.
Expires: May 30, 2015 A. Gulko ISSN: 2070-1721 A. Gulko
Thomson Reuters Thomson Reuters
U. Joorde U. Joorde
Deutsche Telekom Deutsche Telekom
J. Tantsura J. Tantsura
Ericsson Ericsson
November 26, 2014 January 2015
mLDP In-Band Signaling with Wildcards Multipoint LDP (mLDP) In-Band Signaling with Wildcards
draft-ietf-mpls-mldp-in-band-wildcard-encoding-03
Abstract Abstract
There are scenarios in which an IP multicast tree traverses an MPLS There are scenarios in which an IP multicast tree traverses an MPLS
domain. In these scenarios, it can be desirable to convert the IP domain. In these scenarios, it can be desirable to convert the IP
multicast tree "seamlessly" to an MPLS multipoint label switched path multicast tree "seamlessly" into an MPLS Multipoint Label Switched
(MP-LSP) when it enters the MPLS domain, and then to convert it back Path (MP-LSP) when it enters the MPLS domain, and then to convert it
to an IP multicast tree when it exits the MPLS domain. Previous back to an IP multicast tree when it exits the MPLS domain. Previous
documents specify procedures that allow certain kinds of IP multicast documents specify procedures that allow certain kinds of IP multicast
trees (either "Source-Specific Multicast" trees or "Bidirectional trees (either Source-Specific Multicast trees or Bidirectional
Multicast" trees) to be attached to an MPLS Multipoint Label Switched Multicast trees) to be attached to an MPLS Multipoint Label Switched
Path (MP-LSP). However, the previous documents do not specify Path (MP-LSP). However, the previous documents do not specify
procedures for attaching IP "Any Source Multicast" trees to MP-LSPs, procedures for attaching IP Any-Source Multicast trees to MP-LSPs,
nor do they specify procedures for aggregating multiple IP multicast nor do they specify procedures for aggregating multiple IP multicast
trees onto a single MP-LSP. This document specifies the procedures trees onto a single MP-LSP. This document specifies the procedures
to support these functions. It does so by defining "wildcard" to support these functions. It does so by defining "wildcard"
encodings that make it possible to specify, when setting up an MP- 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, 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 should be attached to that MP-LSP. Support for non-bidirectional IP
"Any Source Multicast" trees is subject to certain applicability Any-Source Multicast trees is subject to certain applicability
restrictions that are discussed in this document. This document restrictions that are discussed in this document. This document
updates RFCs 6826 and 7246. updates RFCs 6826 and 7246.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on May 30, 2015. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7438.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Definitions . . . . . . . . . . . . . . . . . 5 2. Terminology and Definitions . . . . . . . . . . . . . . . . . 5
3. Wildcards in mLDP Opaque Value TLVs . . . . . . . . . . . . . 6 3. Wildcards in mLDP Opaque Value TLVs . . . . . . . . . . . . . 7
3.1. Encoding the Wildcards . . . . . . . . . . . . . . . . . 7 3.1. Encoding the Wildcards . . . . . . . . . . . . . . . . . 7
3.2. Wildcard Semantics . . . . . . . . . . . . . . . . . . . 7 3.2. Wildcard Semantics . . . . . . . . . . . . . . . . . . . 8
3.3. Backwards Compatibility . . . . . . . . . . . . . . . . . 8 3.3. Backwards Compatibility . . . . . . . . . . . . . . . . . 8
3.4. Applicability Restrictions with regard to ASM . . . . . . 8 3.4. Applicability Restrictions with Regard to ASM . . . . . . 9
4. Some Wildcard Use Cases . . . . . . . . . . . . . . . . . . . 9 4. Some Wildcard Use Cases . . . . . . . . . . . . . . . . . . . 9
4.1. PIM shared tree forwarding . . . . . . . . . . . . . . . 9 4.1. PIM Shared Tree Forwarding . . . . . . . . . . . . . . . 9
4.2. IGMP/MLD Proxying . . . . . . . . . . . . . . . . . . . . 10 4.2. IGMP/MLD Proxying . . . . . . . . . . . . . . . . . . . . 11
4.3. Selective Source mapping . . . . . . . . . . . . . . . . 10 4.3. Selective Source Mapping . . . . . . . . . . . . . . . . 11
5. Procedures for Wildcard Source Usage . . . . . . . . . . . . 11 5. Procedures for Wildcard Source Usage . . . . . . . . . . . . 11
6. Procedures for Wildcard Group Usage . . . . . . . . . . . . . 12 6. Procedures for Wildcard Group Usage . . . . . . . . . . . . . 13
7. Determining the MP-LSP Root (Ingress LSR) . . . . . . . . . . 12 7. Determining the MP-LSP Root (Ingress LSR) . . . . . . . . . . 13
8. Anycast RP . . . . . . . . . . . . . . . . . . . . . . . . . 13 8. Anycast RP . . . . . . . . . . . . . . . . . . . . . . . . . 13
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
11. Security Considerations . . . . . . . . . . . . . . . . . . . 13 10.1. Normative References . . . . . . . . . . . . . . . . . . 14
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 10.2. Informative References . . . . . . . . . . . . . . . . . 14
12.1. Normative References . . . . . . . . . . . . . . . . . . 13 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 15
12.2. Informative References . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
[RFC6826] and [RFC7246] specify procedures for mLDP ("Multicast [RFC6826] and [RFC7246] specify procedures for mLDP (Multipoint LDP)
Extensions to the Label Distribution Protocol") that allow an IP that allow an IP multicast tree (either a Source-Specific Multicast
multicast tree (either a "Source-Specific Multicast" tree or a tree or a Bidirectional Multicast tree) to be attached "seamlessly"
"Bidirectional multicast" tree) to be attached "seamlessly" to an to an MPLS Multipoint Label Switched Path (MP-LSP). This can be
MPLS Multipoint Label Switched Path (MP-LSP). This can be useful, useful, for example, when there is multicast data that originates in
for example, when there is multicast data that originates in a domain a domain that supports IP multicast, which then has to be forwarded
that supports IP multicast, then has to be forwarded across a domain across a domain that supports MPLS multicast and then has to
that supports MPLS multicast, then has to forwarded across another forwarded across another domain that supports IP multicast. By
domain that supports IP multicast. By attaching an IP multicast tree attaching an IP multicast tree to an MP-LSP, data that is traveling
to an MP-LSP, data that is traveling along the IP multicast tree can along the IP multicast tree can be moved seamlessly to the MP-LSP
be moved seamlessly to the MP-LSP when it enters the MPLS multicast when it enters the MPLS multicast domain. The data then travels
domain. The data then travels along the MP-LSP through the MPLS along the MP-LSP through the MPLS domain. When the data reaches the
domain. When the data reaches the boundary of the MPLS domain, it boundary of the MPLS domain, it can be moved seamlessly to an IP
can be moved seamlessly to an IP multicast tree. This ability to multicast tree. This ability to attach IP multicast trees to MPLS
attach IP multicast trees to MPLS MP-LSPs can be useful in either VPN MP-LSPs can be useful in either VPN context or global context.
context or global context.
In mLDP, every MP-LSP is identified by the combination of a "root In mLDP, every MP-LSP is identified by the combination of a "root
node" (or "Ingress LSR") and an "Opaque Value" that, in the context node" (or "Ingress Label Switching Router (LSR)") and an "Opaque
of the root node, uniquely identifies the MP-LSP. These are encoded Value" that, in the context of the root node, uniquely identifies the
into an mLDP "FEC Element". To set up an MP-LSP, the Egress LSRs MP-LSP. These are encoded into an mLDP "Forwarding Equivalence Class
originate mLDP control messages containing the FEC element. A given (FEC) Element". To set up an MP-LSP, the Egress LSRs originate mLDP
FEC Element value identifies a single MP-LSP, and is passed upstream control messages containing the FEC element. A given FEC Element
from the Egress LSRs, through the intermediate LSRs, to the Ingress value identifies a single MP-LSP and is passed upstream from the
LSR. Egress LSRs, through the intermediate LSRs, to the Ingress LSR.
In IP multicast, a multicast tree is identified by the combination of In IP multicast, a multicast tree is identified by the combination of
an IP source address ("S") and an IP group address ("G"), usually an IP source address ("S") and an IP group address ("G"), usually
written as "(S,G)". A tree carrying traffic of multiple sources is written as "(S,G)". A tree carrying traffic of multiple sources is
identified by its group address, and the identifier is written as identified by its group address, and the identifier is written as
"(*,G)". "(*,G)".
When an MP-LSP is being set up, the procedures of [RFC6826] and When an MP-LSP is being set up, the procedures of [RFC6826] and
[RFC7246], known as "mLDP In-Band Signaling", allow the Egress LSRs [RFC7246], known as "mLDP in-band signaling", allow the Egress LSRs
of the MP-LSP to encode the identifier of an IP multicast tree in the of the MP-LSP to encode the identifier of an IP multicast tree in the
"Opaque Value" field of the mLDP FEC Element that identifies the MP- "Opaque Value" field of the mLDP FEC Element that identifies the MP-
LSP. Only the Egress and Ingress LSRs are aware that the mLDP FEC LSP. Only the Egress and Ingress LSRs are aware that the mLDP FEC
Elements contain encodings of the IP multicast tree identifier; Elements contain encodings of the IP multicast tree identifier;
intermediate nodes along the MP-LSP do not take any account of the intermediate nodes along the MP-LSP do not take any account of the
internal structure of the FEC Element's Opaque Value, and the internal structure of the FEC Element's Opaque Value, and the
internal structure of the Opaque Value does not affect the operation internal structure of the Opaque Value does not affect the operation
of mLDP. By using mLDP In-Band Signaling, the Egress LSRs of an MP- of mLDP. By using mLDP in-band signaling, the Egress LSRs of an MP-
LSP inform the Ingress LSR that they expect traffic of the identified LSP inform the Ingress LSR that they expect traffic of the identified
IP multicast tree (and only that traffic) to be carried on the MP- IP multicast tree (and only that traffic) to be carried on the MP-
LSP. That is, mLDP In-Band Signaling not only sets up the MP-LSP, it LSP. That is, mLDP in-band signaling not only sets up the MP-LSP, it
also binds a given IP multicast tree to the MP-LSP. also binds a given IP multicast tree to the MP-LSP.
If multicast is being done in a VPN context [RFC7246], the mLDP FEC If multicast is being done in a VPN context [RFC7246], then the mLDP
elements also contain a "Route Distinguisher" (RD) (see [RFC7246]), FEC elements also contain a "Route Distinguisher" (RD) (see
as the IP multicast trees are identified not merely by "(S,G)" but by [RFC7246]), as the IP multicast trees are identified not merely by
"(RD,S,G)". The procedures of this document are also applicable in "(S,G)" but by "(RD,S,G)". The procedures of this document are also
this case. Of course, when an Ingress LSR processes an In-Band applicable in this case. Of course, when an Ingress LSR processes an
Signaling Opaque Value that contains an RD, it does so in the context in-band signaling Opaque Value that contains an RD, it does so in the
of the VPN associated with that RD. context of the VPN associated with that RD.
If mLDP In-Band Signaling is not used, some other protocol must be If mLDP in-band signaling is not used, then some other protocol must
used to bind an IP multicast tree to the MP-LSP, and this requires be used to bind an IP multicast tree to the MP-LSP; this requires
additional communication mechanisms between the Ingress LSR and the additional communication mechanisms between the Ingress LSR and the
Egress LSRs of the MP-LSP. The purpose of mLDP In-Band Signaling is Egress LSRs of the MP-LSP. The purpose of mLDP in-band signaling is
to eliminate the need for these other protocols. to eliminate the need for these other protocols.
When following the procedures of [RFC6826] and [RFC7246] for non- When following the procedures of [RFC6826] and [RFC7246] for non-
bidirectional trees, the Opaque Value has an IP Source Address (S) bidirectional trees, the Opaque Value has an IP source address (S)
and an IP Group Address (G) encoded into it, thus enabling it to and an IP group address (G) encoded into it, thus enabling it to
identify a particular IP multicast (S,G) tree. Only a single IP identify a particular IP multicast (S,G) tree. Only a single IP
source-specific multicast tree (i.e., a single "(S,G)") can be source-specific multicast tree (i.e., a single "(S,G)") can be
identified in a given FEC element. As a result, a given MP-LSP can identified in a given FEC element. As a result, a given MP-LSP can
carry data from only a single IP source-specific multicast tree carry data from only a single IP source-specific multicast tree
(i.e., a single "(S,G) tree"). However, there are scenarios in which (i.e., a single "(S,G) tree"). However, there are scenarios in which
it would be desirable to aggregate a number of (S,G) trees on a it would be desirable to aggregate a number of (S,G) trees on a
single MP-LSP. Aggregation allows a given number of IP multicast single MP-LSP. Aggregation allows a given number of IP multicast
trees to use a smaller number of MP-LSPs, thus saving state in the trees to use a smaller number of MP-LSPs, thus saving state in the
network. network.
In addition, [RFC6826] and [RFC7246] do not support the attachment of In addition, [RFC6826] and [RFC7246] do not support the attachment of
an "Any Source Multicast" (ASM) shared tree to an MP-LSP, except in an Any-Source Multicast (ASM) shared tree to an MP-LSP, except in the
the case where the ASM shared tree is a "bidirectional" tree (i.e., a case where the ASM shared tree is a bidirectional tree (i.e., a tree
tree set up by BIDIR-PIM [RFC5015]). However, there are scenarios in set up by BIDIR-PIM [RFC5015]). However, there are scenarios in
which it would be desirable to attach a non-bidirectional ASM shared which it would be desirable to attach a non-bidirectional ASM shared
tree to an MP-LSP. tree to an MP-LSP.
This document specifies a way to encode an mLDP "Opaque Value" in This document specifies a way to encode an mLDP "Opaque Value" in
which either the "S" or the "G" or both are replaced by a "wildcard" which either the "S" or the "G" or both are replaced by a "wildcard"
(written as "*"). Procedures are described for using the wildcard (written as "*"). Procedures are described for using the wildcard
encoding to map non-bidirectional ASM shared trees to MP-LSPs, and encoding to map non-bidirectional ASM shared trees to MP-LSPs and for
for mapping multiple (S,G) trees (with a common value of S or a mapping multiple (S,G) trees (with a common value of S or a common
common value of G) to a single MP-LSP. value of G) to a single MP-LSP.
Some example scenarios where wildcard encoding is useful are: Some example scenarios where wildcard encoding is useful are
o PIM Shared tree forwarding with "threshold infinity". o PIM shared tree forwarding with "threshold infinity";
o IGMP/MLD proxying. o IGMP/Multicast Listener Discovery (MLD) proxying; and
o Selective Source mapping. o Selective Source mapping.
These scenarios are discussed in Section 4. Note that this list of These scenarios are discussed in Section 4. Note that this list of
scenarios is not meant to be exhaustive. scenarios is not meant to be exhaustive.
This draft specifies only the mLDP procedures that are specific to This document specifies only the mLDP procedures that are specific to
the use of wildcards. mLDP In-Band Signaling procedures that are not the use of wildcards. mLDP in-band signaling procedures that are not
specific to the use of wildcards can be found in [RFC6826] and specific to the use of wildcards can be found in [RFC6826] and
[RFC7246]. Unless otherwise specified in this document, those [RFC7246]. Unless otherwise specified in this document, those
procedures still apply when wildcards are used. procedures still apply when wildcards are used.
2. Terminology and Definitions 2. Terminology and Definitions
Readers of this document are assumed to be familiar with the Readers of this document are assumed to be familiar with the
terminology and concepts of the documents listed as Normative terminology and concepts of the documents listed as Normative
References. For convenience, some of the more frequently used terms References. For convenience, some of the more frequently used terms
appear below. appear below.
IGMP: IGMP:
Internet Group Management Protocol. Internet Group Management Protocol.
In-band signaling: In-band signaling:
Using the opaque value of a mLDP FEC element to carry the (S,G) or Using the opaque value of a mLDP FEC element to carry the (S,G) or
(*,G) identifying a particular IP multicast tree. This draft also (*,G) identifying a particular IP multicast tree. This document
allows (S,*) to be encoded in the opaque value; see Section 6. also allows (S,*) to be encoded in the opaque value; see
Section 6.
Ingress LSR: Ingress LSR:
Root node of a MP-LSP. When mLDP In-Band Signaling is used, the Root node of a MP-LSP. When mLDP in-band signaling is used, the
Ingress LSR receives mLDP messages about a particular MP-LSP from Ingress LSR receives mLDP messages about a particular MP-LSP from
"downstream", and emits IP multicast control messages "upstream". downstream and emits IP multicast control messages upstream. The
The set of IP multicast control messages that are emitted upstream set of IP multicast control messages that are emitted upstream
depends upon the contents of the LDP Opaque Value TLVs. The depends upon the contents of the LDP Opaque Value TLVs. The
Ingress LSR also receives IP multicast data messages from Ingress LSR also receives IP multicast data messages from upstream
"upstream" and sends them "downstream" as MPLS packets on a MP- and sends them downstream as MPLS packets on an MP-LSP.
LSP.
IP multicast tree: IP multicast tree:
An IP multicast distribution tree identified by a IP multicast An IP multicast distribution tree identified by an IP multicast
group address and optionally a Source IP address, also referred to group address and optionally a source IP address, also referred to
as (S,G) and (*,G). as (S,G) and (*,G).
MLD: MLD:
Multicast Listener Discovery. Multicast Listener Discovery.
mLDP: mLDP:
Multipoint LDP. Multipoint LDP.
MP-LSP: MP-LSP:
A P2MP or MP2MP LSP. A Point-to-Multipoint (P2MP) or Multipoint-to-Multipoint (MP2MP)
LSP.
PIM: PIM:
Protocol Independent Multicast. Protocol Independent Multicast.
PIM-ASM: PIM-ASM:
PIM Any Source Multicast. PIM Any-Source Multicast.
PIM-SM: PIM-SM:
PIM Sparse Mode PIM Sparse Mode.
PIM-SSM: PIM-SSM:
PIM Source Specific Multicast. PIM Source-Specific Multicast.
RP: RP:
The PIM Rendezvous Point. The PIM Rendezvous Point.
Egress LSR: Egress LSR:
The Egress LSRs of an MP-LSP are LSPs that receive MPLS multicast The Egress LSRs of an MP-LSP are LSPs that receive MPLS multicast
data packets from "upstream" on that MP-LSP, and that forward that data packets from upstream on that MP-LSP, and that forward that
data "downstream" as IP multicast data packets. The Egress LSRs data downstream as IP multicast data packets. The Egress LSRs
also receive IP multicast control messages from "downstream", and also receive IP multicast control messages from downstream and
send mLDP control messages "upstream". When In-Band Signaling is send mLDP control messages upstream. When in-band signaling is
used, the Egress LSRs construct Opaque Value TLVs that contain IP used, the Egress LSRs construct Opaque Value TLVs that contain IP
source and/or group addresses, based on the contents of the IP source and/or group addresses based on the contents of the IP
multicast control messages received from downstream. multicast control messages received from downstream.
Threshold Infinity: Threshold Infinity:
A PIM-SM procedure where no source specific multicast (S,G) trees A PIM-SM procedure where no source-specific multicast (S,G) trees
are created for multicast packets that are forwarded down the are created for multicast packets that are forwarded down the
shared tree (*,G). shared tree (*,G).
TLV: TLV:
A protocol element consisting of a type field, followed by a A protocol element consisting of a type field, followed by a
length field, followed by a value field. Note that the value length field, followed by a value field. Note that the value
field of a TLV may be sub-divided into a number of sub-fields. field of a TLV may be subdivided into a number of subfields.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in RFC "OPTIONAL" in this document are to be interpreted as described in RFC
2119 [RFC2119]. 2119 [RFC2119].
3. Wildcards in mLDP Opaque Value TLVs 3. Wildcards in mLDP Opaque Value TLVs
[RFC6826] and [RFC7246] define the following Opaque Value TLVs: [RFC6826] and [RFC7246] define the following Opaque Value TLVs:
Transit IPv4 Source TLV, Transit IPv6 Source TLV, Transit VPNv4 Transit IPv4 Source TLV, Transit IPv6 Source TLV, Transit VPNv4
Source TLV, and Transit VPNv6 Source TLV. The value field of each Source TLV, and Transit VPNv6 Source TLV. The value field of each
such TLV is divided into a number of sub-fields, one of which such TLV is divided into a number of subfields, one of which contains
contains an IP source address, and one of which contains an IP group an IP source address, and one of which contains an IP group address.
address. Per those documents, these fields must contain valid IP Per those documents, these fields must contain valid IP addresses.
addresses.
This document extends the definition of those TLVs by allowing either This document extends the definition of those TLVs by allowing either
the IP Source Address field or the IP Group Address field (or both) the IP source address field or the IP group address field (or both)
to specify a "wildcard" rather than a valid IP address. to specify a "wildcard" rather than a valid IP address.
3.1. Encoding the Wildcards 3.1. Encoding the Wildcards
A value of all zeroes in the IP Source Address sub-field is used to A value of all zeroes in the IP source address subfield is used to
represent a wildcard source address. A value of all zeroes in the IP represent a wildcard source address. A value of all zeroes in the IP
Group Address sub-field is used to represent the wildcard group group address subfield is used to represent the wildcard group
address. Note that the lengths of these sub-fields are as specified address. Note that the lengths of these subfields are as specified
in the previous documents. in the previous documents.
3.2. Wildcard Semantics 3.2. Wildcard Semantics
If the IP Source Address sub-field contains the wildcard, and the IP If the IP source address subfield contains the wildcard, and the IP
Group Address sub-field contains an IP multicast group address that group address subfield contains an IP multicast group address that is
is NOT in the SSM address range (see Section 4.8 of [RFC4601]), the NOT in the SSM address range (see Section 4.8 of [RFC4601]), then the
TLV identifies a PIM-SM shared tree. Please see Section 3.4 for the TLV identifies a PIM-SM shared tree. Please see Section 3.4 for the
applicability restrictions that apply to this case. applicability restrictions that apply to this case.
If the IP Source Address sub-field contains the wildcard, and the IP If the IP source address subfield contains the wildcard, and the IP
Group Address sub-field contains an IP multicast group address that group address subfield contains an IP multicast group address that is
is in the SSM address range, the TLV identifies the collection of PIM in the SSM address range, then the TLV identifies the collection of
trees with the given group address. PIM trees with the given group address.
If the IP Source Address sub-field contains a non-zero IP address, If the IP source address subfield contains a non-zero IP address, and
and the IP Group Address sub-field contains the wildcard, the TLV the IP group address subfield contains the wildcard, the TLV
identifies the collection of PIM-SSM trees that have the source identifies the collection of PIM-SSM trees that have the source
address as their root. address as their root.
Procedures for the use of the wildcards are discussed in Sections 4, Procedures for the use of the wildcards are discussed in Sections 4,
5 and 6. Please note that, as always, the structure of an Opaque 5, and 6. Please note that, as always, the structure of an Opaque
Value TLV does not affect the operation of mLDP. The structure is Value TLV does not affect the operation of mLDP. The structure is
meaningful only to the IP multicast modules at the ingress and egress meaningful only to the IP multicast modules at the Ingress and Egress
LSRs. LSRs.
Procedures for the use of a wildcard group in the following TLVs Procedures for the use of a wildcard group in the following TLVs
(defined in [RFC6826] or [RFC7246]) are outside the scope of the (defined in [RFC6826] or [RFC7246]) are outside the scope of the
current document: Transit IPv4 Bidir TLV, Transit IPv6 Bidir TLV, current document: Transit IPv4 Bidir TLV, Transit IPv6 Bidir TLV,
Transit VPNv4 Bidir TLV, Transit VPNv6 Bidir TLV. Transit VPNv4 Bidir TLV, and Transit VPNv6 Bidir TLV.
Procedures for the use of both a wildcard source and a wildcard group Procedures for the use of both a wildcard source and a wildcard group
in the same TLV are outside the scope of the current document. in the same TLV are outside the scope of the current document.
Note that the Bidir TLVs do not have a "Source Address" sub-field, Note that the Bidir TLVs do not have a source address subfield, and
and hence the notion of a wildcard source is not applicable to them. hence the notion of a wildcard source is not applicable to them.
3.3. Backwards Compatibility 3.3. Backwards Compatibility
The procedures of this document do not change the behavior described The procedures of this document do not change the behavior described
in [RFC6826] and [RFC7246]. in [RFC6826] and [RFC7246].
A correctly operating Egress LSR that supports [RFC6826] and/or A correctly operating Egress LSR that supports [RFC6826] and/or
[RFC7246], but that does not support this document, will never [RFC7246], but that does not support this document, will never
generate mLDP FEC Element Opaque values that contain source or group generate mLDP FEC Element Opaque values that contain source or group
wildcards. wildcards.
Neither [RFC6826] nor [RFC7246] specifies the behavior of an Ingress Neither [RFC6826] nor [RFC7246] specifies the behavior of an Ingress
LSR that receives mLDP FEC Element Opaque values that contain zeroes LSR that receives mLDP FEC Element Opaque values that contain zeroes
in the Source Address or Group Address sub-fields. However, if an in the source address or group address subfields. However, if an
Ingress LSR supports [RFC6826] and/or [RFC7246], but does not support Ingress LSR supports [RFC6826] and/or [RFC7246], but does not support
this document, it has no choice but to treat any such received FEC this document, then it has no choice but to treat any such received
elements as invalid; the procedures specified in [RFC6826] and FEC elements as invalid; the procedures specified in [RFC6826] and
[RFC7246] do not work when the Opaque values contain zeroes in the [RFC7246] do not work when the Opaque values contain zeroes in the
Source Address or Group Address sub-fields. source address or group address subfields.
The procedures of this document thus presuppose that if an Egress LSR The procedures of this document thus presuppose that if an Egress LSR
uses wildcard encodings when setting up an MP-LSP, then the Ingress uses wildcard encodings when setting up an MP-LSP, then the Ingress
LSR (i.e., the root of the multipoint LSP) supports the procedures of LSR (i.e., the root of the multipoint LSP) supports the procedures of
this document. An Egress LSR MUST NOT use wildcard encodings when this document. An Egress LSR MUST NOT use wildcard encodings when
setting up a particular multipoint LSP unless it is known a priori setting up a particular multipoint LSP unless it is known a priori
that the Ingress LSR supports the procedures of this document. How that the Ingress LSR supports the procedures of this document. How
this is known is outside the scope of this document. this is known is outside the scope of this document.
3.4. Applicability Restrictions with regard to ASM 3.4. Applicability Restrictions with Regard to ASM
In general, support for non-bidirectional PIM-ASM trees requires (a) In general, support for non-bidirectional PIM-ASM trees requires (a)
a procedure for determining the set of sources for a given ASM tree a procedure for determining the set of sources for a given ASM tree
("source discovery"), and (b) a procedure for pruning a particular ("source discovery"), and (b) a procedure for pruning a particular
source off a shared tree ("source pruning"). No such procedures are source off a shared tree ("source pruning"). No such procedures are
specified in this document. Therefore the combination of a wildcard specified in this document. Therefore, the combination of a wildcard
source with an ASM group address MUST NOT be used unless it is known source with an ASM group address MUST NOT be used unless it is known
a priori that neither source discovery nor source pruning are needed. a priori that neither source discovery nor source pruning are needed.
How this is known is outside the scope of this document. Section 4 How this is known is outside the scope of this document. Section 4
describes some use cases in which source discovery and source pruning describes some use cases in which source discovery and source pruning
are not needed. are not needed.
There are of course use cases where source discovery and/or source There are, of course, use cases where source discovery and/or source
pruning is needed. These can be handled with procedures such as pruning is needed. These can be handled with procedures such as
those specified in [RFC6513], [RFC6514], and [GTM]. Use of mLDP In- those specified in [RFC6513], [RFC6514], and [GTM]. Use of mLDP in-
Band Signaling is NOT RECOMMENDED for those cases. band signaling is NOT RECOMMENDED for those cases.
4. Some Wildcard Use Cases 4. Some Wildcard Use Cases
This section discusses a number of wildcard use cases. The set of This section discusses a number of wildcard use cases. The set of
use cases here is not meant to be exhaustive. In each of these use use cases here is not meant to be exhaustive. In each of these use
cases, the Egress LSRs construct mLDP Opaque Value TLVs that contain cases, the Egress LSRs construct mLDP Opaque Value TLVs that contain
wildcards in the IP Source Address or IP Group Address sub-fields. wildcards in the IP source address or IP group address subfields.
4.1. PIM shared tree forwarding 4.1. PIM Shared Tree Forwarding
PIM [RFC4601] has the concept of a "shared tree", identified as PIM [RFC4601] has the concept of a "shared tree", identified as
(*,G). This concept is only applicable when G is an IP Multicast (*,G). This concept is only applicable when G is an IP multicast
Group address that is not in the SSM address range (i.e., is an ASM group address that is not in the SSM address range (i.e., is an ASM
group address). Every ASM group is associated with a Rendezvous group address). Every ASM group is associated with a Rendezvous
Point (RP), and the (*,G) tree is built towards the RP (i.e., its Point (RP), and the (*,G) tree is built towards the RP (i.e., its
root is the RP). The RP for group G is responsible for forwarding root is the RP). The RP for group G is responsible for forwarding
packets down the (*,G) tree. The packets forwarded down the (*,G) packets down the (*,G) tree. The packets forwarded down the (*,G)
tree may be from any multicast source, as long as they have an IP tree may be from any multicast source, as long as they have an IP
destination address of G. destination address of G.
The RP learns about all the multicast sources for a given group, and The RP learns about all the multicast sources for a given group and
then joins a source-specific tree for each such source. I.e., when then joins a source-specific tree for each such source. That is,
the RP for G learns that S has multicast data to send to G, the RP when the RP for G learns that S has multicast data to send to G, the
joins the (S,G) tree. When the RP receives multicast data from S RP joins the (S,G) tree. When the RP receives multicast data from S
that is destined to G, the RP forwards the data down the (*,G) tree. that is destined to G, the RP forwards the data down the (*,G) tree.
There are several different ways that the RP may learn about the There are several different ways that the RP may learn about the
sources for a given group. The RP may learn of sources via PIM sources for a given group. The RP may learn of sources via PIM
Register messages [RFC4601], via MSDP [RFC3618] or by observing Register messages [RFC4601], via Multicast Source Discovery Protocol
packets from a source that is directly connected to the RP. (MSDP) [RFC3618], or by observing packets from a source that is
directly connected to the RP.
In PIM, a PIM router that has receivers for a particular ASM In PIM, a PIM router that has receivers for a particular ASM
multicast group G (known as a "last hop" router for G) will first multicast group G (known as a "last hop" router for G) will first
join the (*,G) tree. As it receives multicast traffic on the (*,G) join the (*,G) tree. As it receives multicast traffic on the (*,G)
tree, it learns (by examining the IP headers of the multicast data tree, it learns (by examining the IP headers of the multicast data
packets) the sources that are transmitting to G. Typically, when a packets) the sources that are transmitting to G. Typically, when a
last hop router for group G learns that source S is transmitting to last hop router for group G learns that source S is transmitting to
G, the last hop router joins the (S,G) tree, and "prunes" S off the G, the last hop router joins the (S,G) tree and "prunes" S off the
(*,G) tree. This allows each last hop router to receive the (*,G) tree. This allows each last hop router to receive the
multicast data along the shortest path from the source to the last multicast data along the shortest path from the source to the last
hop router. (Full details of this behavior can be found in hop router. (Full details of this behavior can be found in
[RFC4601].) [RFC4601].)
In some cases, however, a last hop router for group G may decide not In some cases, however, a last hop router for group G may decide not
to join the source trees, but rather to keep receiving all the to join the source trees, but rather to keep receiving all the
traffic for G from the (*,G) tree. In this case, we say that the traffic for G from the (*,G) tree. In this case, we say that the
last hop router has "threshold infinity" for group G. This is last hop router has "threshold infinity" for group G. This is
optional behaviour documented in [RFC4601]. "Threshold infinity" is optional behavior documented in [RFC4601]. "Threshold infinity" is
often used in deployments where the RP is between the multicast often used in deployments where the RP is between the multicast
sources and the multicast receivers for group G, i.e., in deployments sources and the multicast receivers for group G, i.e., in deployments
where it is known that the shortest path from any source to any where it is known that the shortest path from any source to any
receiver of the group goes through the RP. In these deployments, receiver of the group goes through the RP. In these deployments,
there is no advantage for a last hop router to join a source tree, there is no advantage for a last hop router to join a source tree
since the data is already traveling along the shortest path. The since the data is already traveling along the shortest path. The
only effect of executing the complicated procedures for joining a only effect of executing the complicated procedures for joining a
source tree and pruning the source off the shared tree would be to source tree and pruning the source off the shared tree would be to
increase the amount of multicast routing state that has to be increase the amount of multicast routing state that has to be
maintained in the network. maintained in the network.
To efficiently use mLDP In-Band Signaling in this scenario, it is To efficiently use mLDP in-band signaling in this scenario, it is
necessary for the Egress LSRs to construct an Opaque Value TLV that necessary for the Egress LSRs to construct an Opaque Value TLV that
identifies a (*,G) tree. This is done by using the wildcard in the identifies a (*,G) tree. This is done by using the wildcard in the
IP Source Address sub-field, and setting the IP Group Address sub- IP source address subfield and setting the IP group address subfield
field to G. to G.
Note that these mLDP In-Band Signaling procedures do not support PIM- Note that these mLDP in-band signaling procedures do not support PIM-
ASM in scenarios where "threshold infinity" is not used. ASM in scenarios where "threshold infinity" is not used.
4.2. IGMP/MLD Proxying 4.2. IGMP/MLD Proxying
There are scenarios where the multicast senders and receivers are There are scenarios where the multicast senders and receivers are
directly connected to an MPLS routing domain, and where it is desired directly connected to an MPLS routing domain, and where it is desired
to use mLDP rather than PIM to set up "trees" through that domain. to use mLDP rather than PIM to set up "trees" through that domain.
In these scenarios we can apply "IGMP/MLD proxying" and eliminate the In these scenarios, we can apply "IGMP/MLD proxying" and eliminate
use of PIM. The senders and receivers consider the MPLS domain to be the use of PIM. The senders and receivers consider the MPLS domain
single hop between each other. [RFC4605] documents procedures where to be single hop between each other. [RFC4605] documents procedures
a multicast routing protocol is not necessary to build a 'simple where a multicast routing protocol is not necessary to build a
tree'. Within the MPLS domain, mLDP will be used to build a MP-LSP, "simple tree". Within the MPLS domain, mLDP will be used to build an
but this is hidden from the senders and receivers. The procedures MP-LSP, but this is hidden from the senders and receivers. The
defined in [RFC4605] are applicable, since the senders and receivers procedures defined in [RFC4605] are applicable since the senders and
are considered to be one hop away from each other. receivers are considered to be one hop away from each other.
For mLDP to build the necessary MP-LSP, it needs to know the root of For mLDP to build the necessary MP-LSP, it needs to know the root of
the tree. Following the procedures as defined in [RFC4605] we depend the tree. Following the procedures as defined in [RFC4605], we
on manual configuration of the mLDP root for the ASM multicast group. depend on manual configuration of the mLDP root for the ASM multicast
Since the MP-LSP for a given ASM multicast group will carry traffic group. Since the MP-LSP for a given ASM multicast group will carry
from all the sources for that group, the Opaque Value TLV used to traffic from all the sources for that group, the Opaque Value TLV
construct the MP-LSP will contain a wildcard in the IP Source Address used to construct the MP-LSP will contain a wildcard in the IP source
sub-field. address subfield.
4.3. Selective Source mapping 4.3. Selective Source Mapping
In many IPTV deployments, the content servers are gathered into a In many IPTV deployments, the content servers are gathered into a
small number of sites. Popular channels are often statically small number of sites. Popular channels are often statically
configured, and forwarded over a core MPLS network to the Egress configured and forwarded over a core MPLS network to the Egress
routers. Since these channels are statically defined, they MAY also routers. Since these channels are statically defined, they MAY also
be forwarded over a multipoint LSP with wildcard encoding. The sort be forwarded over a multipoint LSP with wildcard encoding. The sort
of wildcard encoding that needs to be used (Source and/or Group) of wildcard encoding that needs to be used (source and/or group)
depends on the Source/Group allocation policy of the IPTV provider. depends on the source/group allocation policy of the IPTV provider.
Other options are to use MSDP [RFC3618] or BGP "Auto-Discovery" Other options are to use MSDP [RFC3618] or BGP "Auto-Discovery"
procedures [RFC6513] for source discovery by the Ingress LSR. Based procedures [RFC6513] for source discovery by the Ingress LSR. Based
on the received wildcard, the Ingress LSR can select from the set of on the received wildcard, the Ingress LSR can select from the set of
IP multicast streams for which it has state. IP multicast streams for which it has state.
5. Procedures for Wildcard Source Usage 5. Procedures for Wildcard Source Usage
The decision to use mLDP In-Band Signaling is made by the IP The decision to use mLDP in-band signaling is made by the IP
multicast component of an Egress LSR, based on provisioned policy. multicast component of an Egress LSR, based on provisioned policy.
The decision to use (or not to use) a wildcard in the IP Source The decision to use (or not to use) a wildcard in the IP source
Address sub-field of an mLDP Opaque Value TLV is also made by the IP address subfield of an mLDP Opaque Value TLV is also made by the IP
multicast component, again based on provisioned policy. Following multicast component, again based on provisioned policy. Following
are some example policies that may be useful: are some example policies that may be useful:
1. Suppose that PIM is enabled, an Egress LSR needs to join a non- 1. Suppose that PIM is enabled, an Egress LSR needs to join a non-
bidirectional ASM group G, and the RP for G is reachable via a bidirectional ASM group G, and the RP for G is reachable via a
BGP route. The Egress LSR may choose the BGP Next Hop of the BGP route. The Egress LSR may choose the BGP Next Hop of the
route to the RP to be the Ingress LSR (root node) of the MP-LSP route to the RP to be the Ingress LSR (root node) of the MP-LSP
corresponding to the (*,G) tree. (See also Section 7.) The corresponding to the (*,G) tree (see also Section 7). The Egress
Egress LSR may identify the (*,G) tree by using an mLDP Opaque LSR may identify the (*,G) tree by using an mLDP Opaque Value TLV
Value TLV whose IP Source Address sub-field contains a wildcard, whose IP source address subfield contains a wildcard, and whose
and whose IP Group Address sub-field contains G. IP group address subfield contains G.
2. Suppose that PIM is not enabled for group G, and an IGMP/MLD 2. Suppose that PIM is not enabled for group G, and an IGMP/MLD
group membership report for G has been received by an Egress LSR. group membership report for G has been received by an Egress LSR.
The Egress LSR may determine the "proxy device" for G (see The Egress LSR may determine the "proxy device" for G (see
Section 4.2). It can then set up an MP-LSP for which the proxy Section 4.2). It can then set up an MP-LSP for which the proxy
device is the Ingress LSR. The Egress LSR needs to signal the device is the Ingress LSR. The Egress LSR needs to signal the
Ingress LSR that the MP-LSP is to carry traffic belonging to Ingress LSR that the MP-LSP is to carry traffic belonging to
group G; it does this by using an Opaque Value TLV whose IP group G; it does this by using an Opaque Value TLV whose IP
Source Address sub-field contains a wildcard, and whose IP Group source address subfield contains a wildcard, and whose IP group
Address sub-field contains G. address subfield contains G.
As the policies needed in any one deployment may be very different As the policies needed in any one deployment may be very different
than the policies needed in another, this document does not specify than the policies needed in another, this document does not specify
any particular set of policies as being mandatory to implement. any particular set of policies as being mandatory to implement.
When the Ingress LSR receives an mLDP Opaque Value TLV that has been When the Ingress LSR receives an mLDP Opaque Value TLV that has been
defined for In-Band Signaling, the information from the sub-fields of defined for in-band signaling, the information from the subfields of
that TLV is passed to the IP multicast component of the Ingress LSR. that TLV is passed to the IP multicast component of the Ingress LSR.
If the IP Source Address sub-field contains a wildcard, the IP If the IP source address subfield contains a wildcard, the IP
multicast component must determine how to process it. The processing multicast component must determine how to process it. The processing
MUST follow the rules below: MUST follow the rules below:
1. If PIM is enabled and the group identified in the Opaque Value 1. If PIM is enabled and the group identified in the Opaque Value
TLV is a non-bidirectional ASM group, the Ingress LSR acts as if TLV is a non-bidirectional ASM group, the Ingress LSR acts as if
it had received a (*,G) IGMP/MLD report from a downstream node, it had received a (*,G) IGMP/MLD report from a downstream node,
and the procedures defined in [RFC4601] are followed. and the procedures defined in [RFC4601] are followed.
2. If PIM is enabled and the identified group is a PIM-SSM group, 2. If PIM is enabled and the identified group is a PIM-SSM group,
all multicast sources known for the group on the Ingress LSR are all multicast sources known for the group on the Ingress LSR are
to be forwarded down the MP-LSP. In this scenario, it is assumed to be forwarded down the MP-LSP. In this scenario, it is assumed
that the Ingress LSR is already receiving all the necessary that the Ingress LSR is already receiving all the necessary
traffic. How the Ingress LSR receives this traffic is outside traffic. How the Ingress LSR receives this traffic is outside
the scope of this document. the scope of this document.
3. If PIM is not enabled for the identified group, the Ingress LSR 3. If PIM is not enabled for the identified group, the Ingress LSR
acts as if it had received a (*,G) IGMP/MLD report from a acts as if it had received a (*,G) IGMP/MLD report from a
downstream node, and the procedures as defined in [RFC4605] are downstream node, and the procedures as defined in [RFC4605] are
followed. The ingress LSR should forward the (*,G) packets to followed. The Ingress LSR should forward the (*,G) packets to
the egress LSR through the MP-LSP identified by the Opaque Value the Egress LSR through the MP-LSP identified by the Opaque Value
TLV. (See also Section 4.2.) TLV. (See also Section 4.2.)
6. Procedures for Wildcard Group Usage 6. Procedures for Wildcard Group Usage
The decision to use mLDP In-Band Signaling is made by the IP The decision to use mLDP in-band signaling is made by the IP
multicast component of an Egress LSR, based on provisioned policy. multicast component of an Egress LSR based on provisioned policy.
The decision to use (or not to use) a wildcard in the IP Group The decision to use (or not to use) a wildcard in the IP group
Address sub-field of an mLDP Opaque Value TLV is also made by the IP address subfield of an mLDP Opaque Value TLV is also made by the IP
multicast component of the Egress LSR, again based on provisioned multicast component of the Egress LSR, again based on provisioned
policy. As the policies needed in any one deployment may be very policy. As the policies needed in any one deployment may be very
different than the policies needed in another, this document does not different than the policies needed in another, this document does not
specify any particular set of policies as being mandatory to specify any particular set of policies as being mandatory to
implement. implement.
When the Ingress LSR (i.e., the root node of the MP-LSP) receives an When the Ingress LSR (i.e., the root node of the MP-LSP) receives an
mLDP Opaque Value TLV that has been defined for In-Band Signaling, mLDP Opaque Value TLV that has been defined for in-band signaling,
the information from the sub-fields of that TLV is passed to the IP the information from the subfields of that TLV is passed to the IP
multicast component of the Ingress LSR. If the IP Group Address sub- multicast component of the Ingress LSR. If the IP group address
field contains a wildcard, the Ingress LSR examines its IP multicast subfield contains a wildcard, then the Ingress LSR examines its IP
routing table, to find all the IP multicast streams whose IP source multicast routing table to find all the IP multicast streams whose IP
address is the address specified in the IP Source Address sub-field source address is the address specified in the IP source address
of the TLV. All these streams SHOULD be forwarded down the MP-LSP subfield of the TLV. All these streams SHOULD be forwarded down the
identified by the Opaque Value TLV. Note that some of these streams MP-LSP identified by the Opaque Value TLV. Note that some of these
may have SSM group addresses, while some may have ASM group streams may have SSM group addresses, while some may have ASM group
addresses. addresses.
7. Determining the MP-LSP Root (Ingress LSR) 7. Determining the MP-LSP Root (Ingress LSR)
Documents [RFC6826] and [RFC7246] describe procedures by which an [RFC6826] and [RFC7246] describe procedures by which an Egress LSR
Egress LSR may determine the MP-LSP root node address corresponding may determine the MP-LSP root node address corresponding to a given
to a given IP multicast stream, based upon the IP address of the (S,G) IP multicast stream. That determination is based upon the IP
source of the IP multicast stream. When a wildcard source encoding address of the source ("S") of the multicast stream. To follow the
is used, PIM is enabled, and the group is a non-bidirectional ASM procedures of this document, it is necessary to determine the MP-LSP
group, a similar procedure is applied. The only difference from the root node corresponding to a given (*,G) set of IP multicast streams.
above mentioned procedures is that the Proxy device or RP address is The only difference from the above mentioned procedures is that the
used instead of the Source to discover the mLDP root node address. Proxy device or RP address is used instead of the source to discover
the mLDP root node address.
Other procedures for determining the root node are also allowed, as Other procedures for determining the root node are also allowed, as
determined by policy. determined by policy.
8. Anycast RP 8. Anycast RP
In the scenarios where mLDP In-Band Signaling is used, it is unlikely In the scenarios where mLDP in-band signaling is used, it is unlikely
that the RP-to-Group mappings are being dynamically distributed over that the RP-to-group mappings are being dynamically distributed over
the MPLS core. It is more likely that the RP address is statically the MPLS core. It is more likely that the RP address is statically
configured at each multicast site. In these scenarios, it is configured at each multicast site. In these scenarios, it is
advisable to configure an Anycast RP Address at each site, in order advisable to configure an Anycast RP address at each site in order to
to provide redundancy. See [RFC3446] for more details. provide redundancy. See [RFC3446] for more details.
9. Acknowledgements
We would like to thank Loa Andersson, Pranjal Dutta, Lizhong Jin, and
Curtis Villamizar for their review and comments.
10. IANA Considerations
There are no new allocations required from IANA.
11. Security Considerations 9. Security Considerations
There are no security considerations other then ones already There are no security considerations other than ones already
mentioned in [RFC5036], [RFC6826] and [RFC7246]. mentioned in [RFC5036], [RFC6826], and [RFC7246].
12. References 10. References
12.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM): "Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601, August 2006. Protocol Specification (Revised)", RFC 4601, August 2006,
<http://www.rfc-editor.org/info/rfc4601>.
[RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick,
"Internet Group Management Protocol (IGMP) / Multicast "Internet Group Management Protocol (IGMP) / Multicast
Listener Discovery (MLD)-Based Multicast Forwarding Listener Discovery (MLD)-Based Multicast Forwarding
("IGMP/MLD Proxying")", RFC 4605, August 2006. ("IGMP/MLD Proxying")", RFC 4605, August 2006,
<http://www.rfc-editor.org/info/rfc4605>.
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP
Specification", RFC 5036, October 2007. Specification", RFC 5036, October 2007,
<http://www.rfc-editor.org/info/rfc5036>.
[RFC6826] Wijnands, IJ., Eckert, T., Leymann, N., and M. Napierala, [RFC6826] Wijnands, IJ., Eckert, T., Leymann, N., and M. Napierala,
"Multipoint LDP In-Band Signaling for Point-to-Multipoint "Multipoint LDP In-Band Signaling for Point-to-Multipoint
and Multipoint-to-Multipoint Label Switched Paths", RFC and Multipoint-to-Multipoint Label Switched Paths", RFC
6826, January 2013. 6826, January 2013,
<http://www.rfc-editor.org/info/rfc6826>.
[RFC7246] Wijnands, IJ., Hitchen, P., Leymann, N., Henderickx, W., [RFC7246] Wijnands, IJ., Hitchen, P., Leymann, N., Henderickx, W.,
Gulko, A., and J. Tantsura, "Multipoint Label Distribution Gulko, A., and J. Tantsura, "Multipoint Label Distribution
Protocol In-Band Signaling in a Virtual Routing and Protocol In-Band Signaling in a Virtual Routing and
Forwarding (VRF) Table Context", RFC 7246, June 2014. Forwarding (VRF) Table Context", RFC 7246, June 2014,
<http://www.rfc-editor.org/info/rfc7246>.
12.2. Informative References 10.2. Informative References
[GTM] Zhang, J., Giulano, L., Rosen, E., Subramanian, K., [GTM] Zhang, J., Giulano, L., Rosen, E., Subramanian, K.,
Pacella, D., and J. Schiller, "Global Table Multicast with Pacella, D., and J. Schiller, "Global Table Multicast with
BGP-MVPN Procedures", internet-draft draft-ietf-bess-mvpn- BGP-MVPN Procedures", Work in Progress, draft-ietf-bess-
global-table-mcast-00, November 2014. mvpn-global-table-mcast-00, November 2014.
[RFC3446] Kim, D., Meyer, D., Kilmer, H., and D. Farinacci, "Anycast [RFC3446] Kim, D., Meyer, D., Kilmer, H., and D. Farinacci, "Anycast
Rendevous Point (RP) mechanism using Protocol Independent Rendevous Point (RP) mechanism using Protocol Independent
Multicast (PIM) and Multicast Source Discovery Protocol Multicast (PIM) and Multicast Source Discovery Protocol
(MSDP)", RFC 3446, January 2003. (MSDP)", RFC 3446, January 2003,
<http://www.rfc-editor.org/info/rfc3446>.
[RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery [RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery
Protocol (MSDP)", RFC 3618, October 2003. Protocol (MSDP)", RFC 3618, October 2003,
<http://www.rfc-editor.org/info/rfc3618>.
[RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,
"Bidirectional Protocol Independent Multicast (BIDIR- "Bidirectional Protocol Independent Multicast (BIDIR-
PIM)", RFC 5015, October 2007. PIM)", RFC 5015, October 2007,
<http://www.rfc-editor.org/info/rfc5015>.
[RFC6513] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP [RFC6513] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP
VPNs", RFC 6513, February 2012. VPNs", RFC 6513, February 2012,
<http://www.rfc-editor.org/info/rfc6513>.
[RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
Encodings and Procedures for Multicast in MPLS/BGP IP Encodings and Procedures for Multicast in MPLS/BGP IP
VPNs", RFC 6514, February 2012. VPNs", RFC 6514, February 2012,
<http://www.rfc-editor.org/info/rfc6514>.
Acknowledgements
We would like to thank Loa Andersson, Pranjal Dutta, Lizhong Jin, and
Curtis Villamizar for their review and comments.
Authors' Addresses Authors' Addresses
IJsbrand Wijnands (editor) IJsbrand Wijnands (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
De kleetlaan 6a De kleetlaan 6a
Diegem 1831 Diegem 1831
BE Belgium
EMail: ice@cisco.com
Email: ice@cisco.com
Eric C. Rosen Eric C. Rosen
Juniper Networks, Inc. Juniper Networks, Inc.
10 Technology Park Drive 10 Technology Park Drive
Westford, MA 01886 Westford, MA 01886
US United States
Email: erosen@juniper.net EMail: erosen@juniper.net
Arkadiy Gulko Arkadiy Gulko
Thomson Reuters Thomson Reuters
195 Broadway 195 Broadway
New York NY 10007 New York, NY 10007
US United States
Email: arkadiy.gulko@thomsonreuters.com EMail: arkadiy.gulko@thomsonreuters.com
Uwe Joorde Uwe Joorde
Deutsche Telekom Deutsche Telekom
Hammer Str. 216-226 Hammer Str. 216-226
Muenster D-48153 Muenster D-48153
DE Germany
Email: Uwe.Joorde@telekom.de EMail: Uwe.Joorde@telekom.de
Jeff Tantsura Jeff Tantsura
Ericsson Ericsson
300 Holger Way 300 Holger Way
San Jose, CA 95134 San Jose, CA 95134
US United States
Email: jeff.tantsura@ericsson.com EMail: jeff.tantsura@ericsson.com
 End of changes. 118 change blocks. 
255 lines changed or deleted 259 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/