Internet DRAFT - draft-rekhter-pim-sm-over-mldp

draft-rekhter-pim-sm-over-mldp









Network Working Group                   Yakov Rekhter (Juniper Networks)
Internet Draft                         Rahul Aggarwal (Juniper Networks)
Intended Status: Proposed Standard    Nicolai Leymann (Deutsche Telekom)
Expiration Date: February 2012                            August 8, 2011

         Carrying PIM-SM in ASM mode Trees over P2MP mLDP LSPs

                 draft-rekhter-pim-sm-over-mldp-04.txt


Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.


Copyright Notice

   Copyright (c) 2010 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.






Rekhter, Aggarwal, Leymann                                    [Page 1]

Internet Draft    draft-rekhter-pim-sm-over-mldp-04.txt      August 2011


Abstract

   When IP multicast trees created by PIM-SM in ASM mode need to pass
   through an MPLS domain, it may be desirable to map such trees to
   Point-to-Multipoint Label Switched Paths. This document describes how
   to accomplish this in the case where such Point-to-Multipoint Label
   Switches Paths are established using mLDP.


Specification of Requirements

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


1. Introduction

   When IP multicast trees need to pass through an MPLS domain, it may
   be desirable to map such trees to Point-to-Multipoint Label Switched
   Paths (P2MP LSPs). When P2MP LSPs are created by mLDP [mLDP], [MLDP-
   IN-BAND-SIGNALLING] describes how to accomplish this when the trees
   are created by PIM-SM in SSM mode [RFC4607], but does not describe
   how to accomplish this when the trees are created by PIM-SM in ASM
   mode [RFC4601].

   This document describes how a combination of mLDP and BGP can be used
   to accomplish this for multicast trees created by PIM-SM in ASM mode,
   and P2MP LSPs created by mLDP. It describes two possible options for
   doing this.

   This document uses BGP Source Active auto-discovery routes, as
   defined in [MVPN-BGP].

   Like [MLDP-IN-BAND-SIGNALLING], each IP multicast tree is mapped one-
   to-one to a P2MP LSP in the MPLS network. This type of service works
   well if the number of LSPs that are created is under control of the
   MPLS network operator, or if the number of LSPs for a particular
   service are known to be limited in number.

   It is to be noted that the existing BGP MVPN [MVPN-BGP] procedures
   may be used to map Internet IP multicast trees to P2MP LSPs. These
   procedures would accomplish this for IP multicast trees created by
   PIM-SM in SSM mode as well as for IP multicast trees created by PIM-
   SM in ASM mode. Furthermore, these procedures would also support the
   ability to aggregate multiple IP multicast trees to one P2MP LSP in
   the MPLS network. The details of this particular approach are out of
   scope of this document. The approach specified in this document can



Rekhter, Aggarwal, Leymann                                    [Page 2]

Internet Draft    draft-rekhter-pim-sm-over-mldp-04.txt      August 2011


   be viewed as an optimization, compared to the reuse of the entire BGP
   MVPN procedures, and may be beneficial in certain deployment
   scenarios.


2. Option 1

   This option does not transit IP multicast shared trees over the MPLS
   network. Therefore, when an LSR creates (*, G) state (as a result of
   receiving PIM messages on one of its IP multicast interfaces), the
   LSR does not propagate this state in mLDP.


2.1. Originating Source Active auto-discovery routes

   Whenever (as a result of receiving either PIM Register or MSDP
   messages) an RP discovers a new multicast source, the RP SHOULD
   originate a BGP Source Active auto-discovery route. The route carries
   a single MCAST-VPN NLRI constructed as follows:

        + The RD in this NLRI is set to 0.

        + The Multicast Source field MUST be set to S. The Multicast
          Source Length field is set appropriately to reflect this.

        + The Multicast Group field MUST be set to G. The Multicast Group
          Length field is set appropriately to reflect this.

   To constrain distribution of the Source Active auto-discovery route
   to the AS of the advertising RP this route SHOULD carry the NO_EXPORT
   Community ([RFC1997]).

   Using the normal BGP procedures the Source Active auto-discovery
   route is propagated to all other LSRs within the AS.

   Whenever the RP discovers that the source is no longer active, the RP
   MUST withdraw the Source Active auto-discovery route, if such a route
   was previousely advertised by the RP.


2.2. Receiving BGP Source Active auto-discovery route by LSR

   Consider an LSR that has some of its interfaces capable of IP
   multicast and some capable of MPLS multicast.

   When as a result of receiving PIM messages on one of its IP multicast
   interfaces such LSR creates in its Tree Information Base (TIB) a new
   (*, G) entry with a non-empty outgoing interface list that contains



Rekhter, Aggarwal, Leymann                                    [Page 3]

Internet Draft    draft-rekhter-pim-sm-over-mldp-04.txt      August 2011


   one or more IP multicast interfaces, the LSR MUST check if it has any
   Source Active auto-discovery routes for that G. If there is such a
   route, S of that route is reachable via an MPLS interface, and the
   LSR does not have (S, G) state in its TIB for (S, G) carried in the
   route, then the LSR originates the mLDP Label Map with the Transit
   IPv4/IPv6 Source TLV carrying (S,G), as specified in [MLDP-IN-BAND-
   SIGNALLING].

   When an LSR receives a new Source Active auto-discovery route, the
   LSR MUST check if its TIB contains an (*, G) entry with the same G as
   carried in the Source Active auto-discovery route. If such an entry
   is found, S is reachable via an MPLS interface, and the LSR does not
   have (S, G) state in its TIB for (S, G) carried in the route, then
   the LSR originates an mLDP Label Map with the Transit IPv4/IPv6
   Source TLV carrying (S,G), as specified in [MLDP-IN-BAND-SIGNALLING].


2.3. Handling (S, G, RPTbit) state

   Creation and deletion of (S, G, RPTbit) state on a LSR that resulted
   from receiving PIM messages on one of its IP multicast interfaces
   does not result in any mLDP and/or BGP actions by the LSR.


3. Option 2

   This option enables transit of IP multicast shared trees over the
   MPLS network. Therefore, when an LSR creates (*, G) state as a result
   of receiving PIM messages on one of its IP multicast interfaces, the
   LSR does propagate this state in mLDP, as described below.


3.1. In-band signaling for IP Multicast Shared Tree

   To provide support for in-band mLDP signaling of IP multicast shared
   trees this document defines two new mLDP TLVs: Transit IPv4 Shared
   Tree TLV, and Transit IPv6 Shared Tree TLV.

   These two TLVs have exactly the same encoding/format as the IPv4/IPv6
   Source Tree TLVs defined in [MLDP-IN-BAND-SIGNALLING], except that
   instead of the Source field they have the RP field, and this field
   carries the address of the RP.

   Procedures for in-band signaling for IP multicast shared trees with
   mLDP follow the same procedures as for in-band signaling for IP
   multicast source trees specified in [MLDP-IN-BAND-SIGNALLING], except
   that while the latter signals (S,G) state using Transit IPv4/IPv6
   Source TLVs, the former signals (*,G) state using Transit IPv4/IPv6



Rekhter, Aggarwal, Leymann                                    [Page 4]

Internet Draft    draft-rekhter-pim-sm-over-mldp-04.txt      August 2011


   Shared Tree TLVs.


3.2. Originating Source Active auto-discovery routes

   Consider an LSR that has some of its interfaces capable of IP
   multicast and some capable of MPLS multicast.

   Whenever such LSR creates an (S, G) state as a result of receiving an
   mLDP Label Map with the Transit IPv4/IPv6 Source TLV for (S, G), S is
   reachable via one of the IP multicast capable interfaces, and the LSR
   determines that G is in the PIM-SM in ASM mode range, the LSR MUST
   originate a BGP Source Active auto-discovery route. The route carries
   a single MCAST-VPN NLRI constructed as follows:

        + The RD in this NLRI is set to 0.

        + The Multicast Source field MUST be set to S. The Multicast
          Source Length field is set appropriately to reflect this.

        + The Multicast Group field MUST be set to G. The Multicast Group
          Length field is set appropriately to reflect this.

   To constrain distribution of the Source Active auto-discovery route
   to the AS of the advertising LSR this route SHOULD carry the
   NO_EXPORT Community ([RFC1997]).

   Using the normal BGP procedures the Source Active auto-discovery
   route is propagated to all other LSRs within the AS.

   Whenever the LSR deletes the (S, G) state that was previously created
   as a result of receiving an mLDP Label Map with the Transit IPv4/IPv6
   Source TLV for (S, G), the LSR that deletes the state MUST also
   withdraw the Source Active auto-discovery route, if such a route was
   advertised when the state was created.



3.3. Receiving BGP Source Active auto-discovery route

   Procedures for receiving BGP Source Active auto-discovery routes are
   the same as with Option 1.









Rekhter, Aggarwal, Leymann                                    [Page 5]

Internet Draft    draft-rekhter-pim-sm-over-mldp-04.txt      August 2011


3.4. Pruning Sources off the Shared Tree

   If after receiving a new Source Active auto-discovery route for (S,G)
   the LSR determines that (a) it has the (*, G) entry in its TIB, (b)
   the incoming interface list (iif) for that entry contains one of the
   IP interfaces, (c) at least one of the MPLS interfaces is in the
   outgoing interface list (oif) for that entry, and (d) the LSR does
   not originate an mLDP Label Mapping message for (S,G) with the
   Transit IPv4/IPv6 Source TLV, then the LSR MUST transition the
   (S,G,rpt) downstream state to the Prune state. [Conceptually the PIM
   state machine on the LSR will act "as if" it had received
   Prune(S,G,Rpt) on one of its MPLS interfaces, without actually having
   received one.] Depending on the (S,G,rpt) state on the iif, this may
   result in the LSR using PIM procedures to prune S off the Shared
   (*,G) tree.

   The LSR MUST keep the (S,G,rpt) downstream state machine in the Prune
   state for as long as (a) the outgoing interface list (oif) for (*, G)
   contains one of the MPLS interfaces, and (b) the LSR has at least one
   Source Active auto-discovery route for (S,G), and (c) the LSR does
   not originate the mLDP Label Mapping message for (S,G) with the
   Transit IPv4/IPv6 Source TLV. Once either of these conditions become
   no longer valid, the LSR MUST transition the (S,G,rpt) downstream
   state machine to the NoInfo state.

   Note that except for the scenario described in the first paragraph of
   this section, in all other scenarios relying solely on PIM procedures
   on the LSR is sufficient to ensure the correct behavior when pruning
   sources off the shared tree.


3.5. More on handling (S, G, RPTbit) state

   Creation and deletion of (S, G, RPTbit) state on a LSR that resulted
   from receiving PIM messages on one of its IP multicast interfaces
   does not result in any mLDP and/or BGP actions by the LSR.















Rekhter, Aggarwal, Leymann                                    [Page 6]

Internet Draft    draft-rekhter-pim-sm-over-mldp-04.txt      August 2011


4. IANA Considerations

   This document defines two new mLDP TLVs: Transit IPv4 Shared Tree
   TLV, and Transit IPv6 Shared Tree TLV.


5. Security Considerations

   All the security considerations for mLDP apply here.


6. Acknowledgements

   Use of Source Active auto-discovery routes was borrowed from [MVPN-
   BGP]. Some text in this document was borrowed almost verbatim from
   [MVPN-BGP].

   Some of the text in this document was borrowed almost verbatim from
   [MLDP-IN-BAND-SIGNALLING].


7. Normative References

   [mLDP] Minei, I., "Label Distribution Protocol Extensions for Point-
   to- Multipoint and Multipoint-to-Multipoint Label Switched Paths",
   draft-ietf-mpls-ldp-p2mp-05 (work in progress), June 2008.

   [MLDP-IN-BAND-SIGNALLING] "In-band signaling for Point-to-Multipoint
   and Multipoint-to-Multipoint Label Switched Paths", I. Wijnands et
   al., draft-wijnands-mpls-mldp-in-band-signaling (work in progress)

   [MVPN-BGP] "BGP Encodings and Procedures for Multicast in MPLS/BGP IP
   VPNs", R. Aggarwal et al., draft-ietf-l3vpn-2547bis-mcast-bgp (work
   in progress)

   [RFC1997]

   [RFC2119]













Rekhter, Aggarwal, Leymann                                    [Page 7]

Internet Draft    draft-rekhter-pim-sm-over-mldp-04.txt      August 2011


8. Non-normative References

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

   [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for
   IP", RFC 4607, August 2006.


9. Authors' Addresses


   Yakov Rekhter
   Juniper Networks, Inc.
   e-mail: yakov@juniper.net

   Rahul Aggarwal
   Juniper Networks, Inc.
   e-mail: rahul@juniper.net

   Nicolai Leymann
   Deutsche Telekom
   Winterfeldtstrasse 21
   Berlin  10781
   Germany

   Email: nicolai.leymann@t-systems.com























Rekhter, Aggarwal, Leymann                                    [Page 8]