Internet DRAFT - draft-ietf-mpls-mldp-in-band-wildcard-encoding

draft-ietf-mpls-mldp-in-band-wildcard-encoding







MPLS Working Group                                     IJ. Wijnands, Ed.
Internet-Draft                                       Cisco Systems, Inc.
Updates: 6826,7246 (if approved)                                E. Rosen
Intended status: Standards Track                  Juniper Networks, Inc.
Expires: May 30, 2015                                           A. Gulko
                                                         Thomson Reuters
                                                               U. Joorde
                                                        Deutsche Telekom
                                                             J. Tantsura
                                                                Ericsson
                                                       November 26, 2014


                 mLDP In-Band Signaling with Wildcards
           draft-ietf-mpls-mldp-in-band-wildcard-encoding-03

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.  This document
   updates RFCs 6826 and 7246.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   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/.




Wijnands, et al.          Expires May 30, 2015                  [Page 1]

Internet-Draft    mLDP In-Band Signaling with Wildcards    November 2014


   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on May 30, 2015.

Copyright Notice

   Copyright (c) 2014 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology and Definitions . . . . . . . . . . . . . . . . .   5
   3.  Wildcards in mLDP Opaque Value TLVs . . . . . . . . . . . . .   6
     3.1.  Encoding the Wildcards  . . . . . . . . . . . . . . . . .   7
     3.2.  Wildcard Semantics  . . . . . . . . . . . . . . . . . . .   7
     3.3.  Backwards Compatibility . . . . . . . . . . . . . . . . .   8
     3.4.  Applicability Restrictions with regard to ASM . . . . . .   8
   4.  Some Wildcard Use Cases . . . . . . . . . . . . . . . . . . .   9
     4.1.  PIM shared tree forwarding  . . . . . . . . . . . . . . .   9
     4.2.  IGMP/MLD Proxying . . . . . . . . . . . . . . . . . . . .  10
     4.3.  Selective Source mapping  . . . . . . . . . . . . . . . .  10
   5.  Procedures for Wildcard Source Usage  . . . . . . . . . . . .  11
   6.  Procedures for Wildcard Group Usage . . . . . . . . . . . . .  12
   7.  Determining the MP-LSP Root (Ingress LSR) . . . . . . . . . .  12
   8.  Anycast RP  . . . . . . . . . . . . . . . . . . . . . . . . .  13
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  13
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
   11. Security Considerations . . . . . . . . . . . . . . . . . . .  13
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  13
     12.1.  Normative References . . . . . . . . . . . . . . . . . .  13
     12.2.  Informative References . . . . . . . . . . . . . . . . .  14
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14





Wijnands, et al.          Expires May 30, 2015                  [Page 2]

Internet-Draft    mLDP In-Band Signaling with Wildcards    November 2014


1.  Introduction

   [RFC6826] and [RFC7246] specify procedures for mLDP ("Multicast
   Extensions to the Label Distribution Protocol") that allow an IP
   multicast tree (either a "Source-Specific Multicast" tree or a
   "Bidirectional multicast" tree) to be attached "seamlessly" to an
   MPLS Multipoint Label Switched Path (MP-LSP).  This can be useful,
   for example, when there is multicast data that originates in a domain
   that supports IP multicast, then has to be forwarded across a domain
   that supports MPLS multicast, then has to forwarded across another
   domain that supports IP multicast.  By attaching an IP multicast tree
   to an MP-LSP, data that is traveling along the IP multicast tree can
   be moved seamlessly to the MP-LSP when it enters the MPLS multicast
   domain.  The data then travels along the MP-LSP through the MPLS
   domain.  When the data reaches the boundary of the MPLS domain, it
   can be moved seamlessly to an IP multicast tree.  This ability to
   attach IP multicast trees to MPLS MP-LSPs can be useful in either VPN
   context or global context.

   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
   of the root node, uniquely identifies the MP-LSP.  These are encoded
   into an mLDP "FEC Element".  To set up an MP-LSP, the Egress LSRs
   originate mLDP control messages containing the FEC element.  A given
   FEC Element value identifies a single MP-LSP, and is passed upstream
   from the Egress LSRs, through the intermediate LSRs, to the Ingress
   LSR.

   In IP multicast, a multicast tree is identified by the combination of
   an IP source address ("S") and an IP group address ("G"), usually
   written as "(S,G)".  A tree carrying traffic of multiple sources is
   identified by its group address, and the identifier is written as
   "(*,G)".

   When an MP-LSP is being set up, the procedures of [RFC6826] and
   [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
   "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
   Elements contain encodings of the IP multicast tree identifier;
   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 Opaque Value does not affect the operation
   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
   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
   also binds a given IP multicast tree to the MP-LSP.



Wijnands, et al.          Expires May 30, 2015                  [Page 3]

Internet-Draft    mLDP In-Band Signaling with Wildcards    November 2014


   If multicast is being done in a VPN context [RFC7246], the mLDP FEC
   elements also contain a "Route Distinguisher" (RD) (see [RFC7246]),
   as the IP multicast trees are identified not merely by "(S,G)" but by
   "(RD,S,G)".  The procedures of this document are also applicable in
   this case.  Of course, when an Ingress LSR processes an In-Band
   Signaling Opaque Value that contains an RD, it does so in the context
   of the VPN associated with that RD.

   If mLDP In-Band Signaling is not used, some other protocol must be
   used to bind an IP multicast tree to the MP-LSP, and this requires
   additional communication mechanisms between the Ingress LSR and the
   Egress LSRs of the MP-LSP.  The purpose of mLDP In-Band Signaling is
   to eliminate the need for these other protocols.

   When following the procedures of [RFC6826] and [RFC7246] for non-
   bidirectional trees, the Opaque Value has an IP Source Address (S)
   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
   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
   carry data from only a single IP source-specific multicast tree
   (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
   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
   network.

   In addition, [RFC6826] and [RFC7246] do not support the attachment of
   an "Any Source Multicast" (ASM) shared tree to an MP-LSP, except in
   the case where the ASM shared tree is a "bidirectional" tree (i.e., a
   tree set up by BIDIR-PIM [RFC5015]).  However, there are scenarios in
   which it would be desirable to attach a non-bidirectional ASM shared
   tree to an MP-LSP.

   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"
   (written as "*").  Procedures are described for using the wildcard
   encoding to map non-bidirectional ASM shared trees to MP-LSPs, and
   for mapping multiple (S,G) trees (with a common value of S or a
   common value of G) to a single MP-LSP.

   Some example scenarios where wildcard encoding is useful are:

   o  PIM Shared tree forwarding with "threshold infinity".

   o  IGMP/MLD proxying.

   o  Selective Source mapping.



Wijnands, et al.          Expires May 30, 2015                  [Page 4]

Internet-Draft    mLDP In-Band Signaling with Wildcards    November 2014


   These scenarios are discussed in Section 4.  Note that this list of
   scenarios is not meant to be exhaustive.

   This draft specifies only the mLDP procedures that are specific to
   the use of wildcards.  mLDP In-Band Signaling procedures that are not
   specific to the use of wildcards can be found in [RFC6826] and
   [RFC7246].  Unless otherwise specified in this document, those
   procedures still apply when wildcards are used.

2.  Terminology and Definitions

   Readers of this document are assumed to be familiar with the
   terminology and concepts of the documents listed as Normative
   References.  For convenience, some of the more frequently used terms
   appear below.

   IGMP:
      Internet Group Management Protocol.

   In-band signaling:
      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
      allows (S,*) to be encoded in the opaque value; see Section 6.

   Ingress LSR:
      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
      "downstream", and emits IP multicast control messages "upstream".
      The set of IP multicast control messages that are emitted upstream
      depends upon the contents of the LDP Opaque Value TLVs.  The
      Ingress LSR also receives IP multicast data messages from
      "upstream" and sends them "downstream" as MPLS packets on a MP-
      LSP.

   IP multicast tree:
      An IP multicast distribution tree identified by a IP multicast
      group address and optionally a Source IP address, also referred to
      as (S,G) and (*,G).

   MLD:
      Multicast Listener Discovery.

   mLDP:
      Multipoint LDP.

   MP-LSP:
      A P2MP or MP2MP LSP.




Wijnands, et al.          Expires May 30, 2015                  [Page 5]

Internet-Draft    mLDP In-Band Signaling with Wildcards    November 2014


   PIM:
      Protocol Independent Multicast.

   PIM-ASM:
      PIM Any Source Multicast.

   PIM-SM:
      PIM Sparse Mode

   PIM-SSM:
      PIM Source Specific Multicast.

   RP:
      The PIM Rendezvous Point.

   Egress LSR:
      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 "downstream" as IP multicast data packets.  The Egress LSRs
      also receive IP multicast control messages from "downstream", and
      send mLDP control messages "upstream".  When In-Band Signaling is
      used, the Egress LSRs construct Opaque Value TLVs that contain IP
      source and/or group addresses, based on the contents of the IP
      multicast control messages received from downstream.

   Threshold Infinity:
      A PIM-SM procedure where no source specific multicast (S,G) trees
      are created for multicast packets that are forwarded down the
      shared tree (*,G).

   TLV:
      A protocol element consisting of a type field, followed by a
      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.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in RFC
   2119 [RFC2119].

3.  Wildcards in mLDP Opaque Value TLVs

   [RFC6826] and [RFC7246] define the following Opaque Value TLVs:
   Transit IPv4 Source TLV, Transit IPv6 Source TLV, Transit VPNv4
   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
   contains an IP source address, and one of which contains an IP group




Wijnands, et al.          Expires May 30, 2015                  [Page 6]

Internet-Draft    mLDP In-Band Signaling with Wildcards    November 2014


   address.  Per those documents, these fields must contain valid IP
   addresses.

   This document extends the definition of those TLVs by allowing either
   the IP Source Address field or the IP Group Address field (or both)
   to specify a "wildcard" rather than a valid IP address.

3.1.  Encoding the Wildcards

   A value of all zeroes in the IP Source Address sub-field is used to
   represent a wildcard source address.  A value of all zeroes in the IP
   Group Address sub-field is used to represent the wildcard group
   address.  Note that the lengths of these sub-fields are as specified
   in the previous documents.

3.2.  Wildcard Semantics

   If the IP Source Address sub-field contains the wildcard, and the IP
   Group Address sub-field contains an IP multicast group address that
   is NOT in the SSM address range (see Section 4.8 of [RFC4601]), the
   TLV identifies a PIM-SM shared tree.  Please see Section 3.4 for the
   applicability restrictions that apply to this case.

   If the IP Source Address sub-field contains the wildcard, and the IP
   Group Address sub-field contains an IP multicast group address that
   is in the SSM address range, the TLV identifies the collection of PIM
   trees with the given group address.

   If the IP Source Address sub-field contains a non-zero IP address,
   and the IP Group Address sub-field contains the wildcard, the TLV
   identifies the collection of PIM-SSM trees that have the source
   address as their root.

   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
   Value TLV does not affect the operation of mLDP.  The structure is
   meaningful only to the IP multicast modules at the ingress and egress
   LSRs.

   Procedures for the use of a wildcard group in the following TLVs
   (defined in [RFC6826] or [RFC7246]) are outside the scope of the
   current document: Transit IPv4 Bidir TLV, Transit IPv6 Bidir TLV,
   Transit VPNv4 Bidir TLV, Transit VPNv6 Bidir TLV.

   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.





Wijnands, et al.          Expires May 30, 2015                  [Page 7]

Internet-Draft    mLDP In-Band Signaling with Wildcards    November 2014


   Note that the Bidir TLVs do not have a "Source Address" sub-field,
   and hence the notion of a wildcard source is not applicable to them.

3.3.  Backwards Compatibility

   The procedures of this document do not change the behavior described
   in [RFC6826] and [RFC7246].

   A correctly operating Egress LSR that supports [RFC6826] and/or
   [RFC7246], but that does not support this document, will never
   generate mLDP FEC Element Opaque values that contain source or group
   wildcards.

   Neither [RFC6826] nor [RFC7246] specifies the behavior of an Ingress
   LSR that receives mLDP FEC Element Opaque values that contain zeroes
   in the Source Address or Group Address sub-fields.  However, if an
   Ingress LSR supports [RFC6826] and/or [RFC7246], but does not support
   this document, it has no choice but to treat any such received FEC
   elements as invalid; the procedures specified in [RFC6826] and
   [RFC7246] do not work when the Opaque values contain zeroes in the
   Source Address or Group Address sub-fields.

   The procedures of this document thus presuppose that if an Egress LSR
   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
   this document.  An Egress LSR MUST NOT use wildcard encodings when
   setting up a particular multipoint LSP unless it is known a priori
   that the Ingress LSR supports the procedures of this document.  How
   this is known is outside the scope of this document.

3.4.  Applicability Restrictions with regard to ASM

   In general, support for non-bidirectional PIM-ASM trees requires (a)
   a procedure for determining the set of sources for a given ASM tree
   ("source discovery"), and (b) a procedure for pruning a particular
   source off a shared tree ("source pruning").  No such procedures are
   specified in this document.  Therefore the combination of a wildcard
   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.
   How this is known is outside the scope of this document.  Section 4
   describes some use cases in which source discovery and source pruning
   are not needed.

   There are of course use cases where source discovery and/or source
   pruning is needed.  These can be handled with procedures such as
   those specified in [RFC6513], [RFC6514], and [GTM].  Use of mLDP In-
   Band Signaling is NOT RECOMMENDED for those cases.




Wijnands, et al.          Expires May 30, 2015                  [Page 8]

Internet-Draft    mLDP In-Band Signaling with Wildcards    November 2014


4.  Some Wildcard Use Cases

   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
   cases, the Egress LSRs construct mLDP Opaque Value TLVs that contain
   wildcards in the IP Source Address or IP Group Address sub-fields.

4.1.  PIM shared tree forwarding

   PIM [RFC4601] has the concept of a "shared tree", identified as
   (*,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).  Every ASM group is associated with a Rendezvous
   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
   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
   destination address of G.

   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
   the RP for G learns that S has multicast data to send to G, the 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.
   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
   Register messages [RFC4601], via 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
   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)
   tree, it learns (by examining the IP headers of the multicast data
   packets) the sources that are transmitting to G.  Typically, when a
   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) tree.  This allows each last hop router to receive the
   multicast data along the shortest path from the source to the last
   hop router.  (Full details of this behavior can be found in
   [RFC4601].)

   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
   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
   optional behaviour documented in [RFC4601].  "Threshold infinity" is
   often used in deployments where the RP is between the multicast
   sources and the multicast receivers for group G, i.e., in deployments



Wijnands, et al.          Expires May 30, 2015                  [Page 9]

Internet-Draft    mLDP In-Band Signaling with Wildcards    November 2014


   where it is known that the shortest path from any source to any
   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,
   since the data is already traveling along the shortest path.  The
   only effect of executing the complicated procedures for joining a
   source tree and pruning the source off the shared tree would be to
   increase the amount of multicast routing state that has to be
   maintained in the network.

   To efficiently use mLDP In-Band Signaling in this scenario, it is
   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
   IP Source Address sub-field, and setting the IP Group Address sub-
   field to G.

   Note that these mLDP In-Band Signaling procedures do not support PIM-
   ASM in scenarios where "threshold infinity" is not used.

4.2.  IGMP/MLD Proxying

   There are scenarios where the multicast senders and receivers are
   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.

   In these scenarios we can apply "IGMP/MLD proxying" and eliminate the
   use of PIM.  The senders and receivers consider the MPLS domain to be
   single hop between each other.  [RFC4605] documents procedures where
   a multicast routing protocol is not necessary to build a 'simple
   tree'.  Within the MPLS domain, mLDP will be used to build a MP-LSP,
   but this is hidden from the senders and receivers.  The procedures
   defined in [RFC4605] are applicable, since the senders and 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
   the tree.  Following the procedures as defined in [RFC4605] we depend
   on manual configuration of the mLDP root for the ASM multicast group.
   Since the MP-LSP for a given ASM multicast group will carry traffic
   from all the sources for that group, the Opaque Value TLV used to
   construct the MP-LSP will contain a wildcard in the IP Source Address
   sub-field.

4.3.  Selective Source mapping

   In many IPTV deployments, the content servers are gathered into a
   small number of sites.  Popular channels are often statically
   configured, and forwarded over a core MPLS network to the Egress
   routers.  Since these channels are statically defined, they MAY also
   be forwarded over a multipoint LSP with wildcard encoding.  The sort



Wijnands, et al.          Expires May 30, 2015                 [Page 10]

Internet-Draft    mLDP In-Band Signaling with Wildcards    November 2014


   of wildcard encoding that needs to be used (Source and/or Group)
   depends on the Source/Group allocation policy of the IPTV provider.
   Other options are to use MSDP [RFC3618] or BGP "Auto-Discovery"
   procedures [RFC6513] for source discovery by the Ingress LSR.  Based
   on the received wildcard, the Ingress LSR can select from the set of
   IP multicast streams for which it has state.

5.  Procedures for Wildcard Source Usage

   The decision to use mLDP In-Band Signaling is made by the IP
   multicast component of an Egress LSR, based on provisioned policy.
   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
   multicast component, again based on provisioned policy.  Following
   are some example policies that may be useful:

   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
       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
       corresponding to the (*,G) tree.  (See also Section 7.)  The
       Egress LSR may identify the (*,G) tree by using an mLDP Opaque
       Value TLV whose IP Source Address sub-field contains a wildcard,
       and whose IP Group Address sub-field contains G.

   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.
       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
       device is the Ingress LSR.  The Egress LSR needs to signal the
       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
       Source Address sub-field contains a wildcard, and whose IP Group
       Address sub-field contains G.

   As the policies needed in any one deployment may be very different
   than the policies needed in another, this document does not specify
   any particular set of policies as being mandatory to implement.

   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
   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
   multicast component must determine how to process it.  The processing
   MUST follow the rules below:

   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



Wijnands, et al.          Expires May 30, 2015                 [Page 11]

Internet-Draft    mLDP In-Band Signaling with Wildcards    November 2014


       it had received a (*,G) IGMP/MLD report from a downstream node,
       and the procedures defined in [RFC4601] are followed.

   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
       to be forwarded down the MP-LSP.  In this scenario, it is assumed
       that the Ingress LSR is already receiving all the necessary
       traffic.  How the Ingress LSR receives this traffic is outside
       the scope of this document.

   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
       downstream node, and the procedures as defined in [RFC4605] are
       followed.  The ingress LSR should forward the (*,G) packets to
       the egress LSR through the MP-LSP identified by the Opaque Value
       TLV.  (See also Section 4.2.)

6.  Procedures for Wildcard Group Usage

   The decision to use mLDP In-Band Signaling is made by the IP
   multicast component of an Egress LSR, based on provisioned policy.
   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
   multicast component of the Egress LSR, again based on provisioned
   policy.  As the policies needed in any one deployment may be very
   different than the policies needed in another, this document does not
   specify any particular set of policies as being mandatory to
   implement.

   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,
   the information from the sub-fields of that TLV is passed to the IP
   multicast component of the Ingress LSR.  If the IP Group Address sub-
   field contains a wildcard, the Ingress LSR examines its IP multicast
   routing table, to find all the IP multicast streams whose IP source
   address is the address specified in the IP Source Address sub-field
   of the TLV.  All these streams SHOULD be forwarded down the MP-LSP
   identified by the Opaque Value TLV.  Note that some of these streams
   may have SSM group addresses, while some may have ASM group
   addresses.

7.  Determining the MP-LSP Root (Ingress LSR)

   Documents [RFC6826] and [RFC7246] describe procedures by which an
   Egress LSR may determine the MP-LSP root node address corresponding
   to a given IP multicast stream, based upon the IP address of the
   source of the IP multicast stream.  When a wildcard source encoding
   is used, PIM is enabled, and the group is a non-bidirectional ASM



Wijnands, et al.          Expires May 30, 2015                 [Page 12]

Internet-Draft    mLDP In-Band Signaling with Wildcards    November 2014


   group, a similar procedure is applied.  The only difference from the
   above mentioned procedures is that the 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
   determined by policy.

8.  Anycast RP

   In the scenarios where mLDP In-Band Signaling is used, it is unlikely
   that the RP-to-Group mappings are being dynamically distributed over
   the MPLS core.  It is more likely that the RP address is statically
   configured at each multicast site.  In these scenarios, it is
   advisable to configure an Anycast RP Address at each site, in order
   to 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

   There are no security considerations other then ones already
   mentioned in [RFC5036], [RFC6826] and [RFC7246].

12.  References

12.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4601]  Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
              "Protocol Independent Multicast - Sparse Mode (PIM-SM):
              Protocol Specification (Revised)", RFC 4601, August 2006.

   [RFC4605]  Fenner, B., He, H., Haberman, B., and H. Sandick,
              "Internet Group Management Protocol (IGMP) / Multicast
              Listener Discovery (MLD)-Based Multicast Forwarding
              ("IGMP/MLD Proxying")", RFC 4605, August 2006.

   [RFC5036]  Andersson, L., Minei, I., and B. Thomas, "LDP
              Specification", RFC 5036, October 2007.



Wijnands, et al.          Expires May 30, 2015                 [Page 13]

Internet-Draft    mLDP In-Band Signaling with Wildcards    November 2014


   [RFC6826]  Wijnands, IJ., Eckert, T., Leymann, N., and M. Napierala,
              "Multipoint LDP In-Band Signaling for Point-to-Multipoint
              and Multipoint-to-Multipoint Label Switched Paths", RFC
              6826, January 2013.

   [RFC7246]  Wijnands, IJ., Hitchen, P., Leymann, N., Henderickx, W.,
              Gulko, A., and J. Tantsura, "Multipoint Label Distribution
              Protocol In-Band Signaling in a Virtual Routing and
              Forwarding (VRF) Table Context", RFC 7246, June 2014.

12.2.  Informative References

   [GTM]      Zhang, J., Giulano, L., Rosen, E., Subramanian, K.,
              Pacella, D., and J. Schiller, "Global Table Multicast with
              BGP-MVPN Procedures", internet-draft draft-ietf-bess-mvpn-
              global-table-mcast-00, November 2014.

   [RFC3446]  Kim, D., Meyer, D., Kilmer, H., and D. Farinacci, "Anycast
              Rendevous Point (RP) mechanism using Protocol Independent
              Multicast (PIM) and Multicast Source Discovery Protocol
              (MSDP)", RFC 3446, January 2003.

   [RFC3618]  Fenner, B. and D. Meyer, "Multicast Source Discovery
              Protocol (MSDP)", RFC 3618, October 2003.

   [RFC5015]  Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,
              "Bidirectional Protocol Independent Multicast (BIDIR-
              PIM)", RFC 5015, October 2007.

   [RFC6513]  Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP
              VPNs", RFC 6513, February 2012.

   [RFC6514]  Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
              Encodings and Procedures for Multicast in MPLS/BGP IP
              VPNs", RFC 6514, February 2012.

Authors' Addresses

   IJsbrand Wijnands (editor)
   Cisco Systems, Inc.
   De kleetlaan 6a
   Diegem  1831
   BE

   Email: ice@cisco.com






Wijnands, et al.          Expires May 30, 2015                 [Page 14]

Internet-Draft    mLDP In-Band Signaling with Wildcards    November 2014


   Eric C. Rosen
   Juniper Networks, Inc.
   10 Technology Park Drive
   Westford, MA  01886
   US

   Email: erosen@juniper.net


   Arkadiy Gulko
   Thomson Reuters
   195 Broadway
   New York  NY 10007
   US

   Email: arkadiy.gulko@thomsonreuters.com


   Uwe Joorde
   Deutsche Telekom
   Hammer Str. 216-226
   Muenster  D-48153
   DE

   Email: Uwe.Joorde@telekom.de


   Jeff Tantsura
   Ericsson
   300 Holger Way
   San Jose, CA  95134
   US

   Email: jeff.tantsura@ericsson.com

















Wijnands, et al.          Expires May 30, 2015                 [Page 15]