GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc7442

Internet Engineering Task Force (IETF) Y. Rekhter Request for Comments: 7442 Juniper Networks Category: Standards Track R. Aggarwal ISSN: 2070-1721 Arktan

                                                            N. Leymann
                                                      Deutsche Telekom
                                                         W. Henderickx
                                                        Alcatel-Lucent
                                                               Q. Zhao
                                                                 R. Li
                                                                Huawei
                                                         February 2015
   Carrying Protocol Independent Multicast - Sparse Mode (PIM-SM)
in Any-Source Multicast (ASM) Mode Trees over Multipoint LDP (mLDP)

Abstract

 When IP multicast trees created by Protocol Independent Multicast -
 Sparse Mode (PIM-SM) in Any-Source Multicast (ASM) mode need to pass
 through an MPLS domain, it may be desirable to map such trees to
 Point-to-Multipoint Label Switched Paths (P2MP LSPs).  This document
 describes how to accomplish this in the case where such P2MP LSPs are
 established using Label Distribution Protocol (LDP) Extensions for
 P2MP and Multipoint-to-Multipoint LSPs: Multipoint LDP (mLDP).

Status of This Memo

 This is an Internet Standards Track document.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Further information on
 Internet Standards is available in Section 2 of RFC 5741.
 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/rfc7442.

Rekhter, et al. Standards Track [Page 1] RFC 7442 PIM-SM over P2MP mLDP LSPs February 2015

Copyright Notice

 Copyright (c) 2015 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
    1.1. Specification of Requirements ..............................4
 2. Mechanism 1 - Non-transitive Mapping of IP Multicast
    Shared Trees ....................................................4
    2.1. Originating Source Active Auto-discovery Routes
         (Mechanism 1) ..............................................4
    2.2. Receiving Source Active Auto-discovery Routes by LSR .......5
    2.3. Handling (S,G,RPT-bit) State ...............................5
 3. Mechanism 2 - Transitive Mapping of IP Multicast Shared Trees ...6
    3.1. In-Band Signaling for IP Multicast Shared Trees ............6
    3.2. Originating Source Active Auto-discovery Routes
         (Mechanism 2) ..............................................7
    3.3. Receiving Source Active Auto-discovery Routes ..............8
    3.4. Pruning Sources Off the Shared Tree ........................8
    3.5. More on Handling (S,G,RPT-bit) State .......................9
 4. IANA Considerations .............................................9
 5. Security Considerations .........................................9
 6. References .....................................................10
    6.1. Normative References ......................................10
    6.2. Informative References ....................................10
 Acknowledgements ..................................................11
 Authors' Addresses ................................................11

Rekhter, et al. Standards Track [Page 2] RFC 7442 PIM-SM over P2MP mLDP LSPs February 2015

1. Introduction

 [RFC6826] describes how to map Point-to-Multipoint Label Switched
 Paths (P2MP LSPs) created by mLDP [RFC6388] to multicast trees
 created by Protocol Independent Multicast - Sparse Mode (PIM-SM) in
 Source-Specific Multicast (SSM) mode [RFC4607].  This document
 describes how to map mLDP P2MP trees to multicast trees created by
 PIM-SM in Any-Source Multicast (ASM) mode.  It describes two possible
 mechanisms for doing this.
 The first mechanism, described in Section 2, is OPTIONAL for
 implementations, but the second mechanism, described in Section 3, is
 REQUIRED for all implementations claiming conformance to this
 specification.
 Note that from a deployment point of view these two mechanisms are
 mutually exclusive.  That is, on the same network one could deploy
 either one of the mechanisms, but not both.
 The reader of this document is expected to be familiar with PIM-SM
 [RFC4601] and mLDP [RFC6388].
 This document relies on the procedures in [RFC6826] to support source
 trees.  For example, following these procedures a Label Switching
 Router (LSR) may initiate an mLDP Label Map with the Transit
 IPv4/IPv6 Source TLV for (S,G) when receiving a PIM (S,G) Join.
 This document uses BGP Source Active auto-discovery routes, as
 defined in [RFC6514].  For the sake of brevity in the rest of this
 document, we'll refer to these routes as just "Source Active
 auto-discovery routes".
 Consider a deployment scenario where the service provider has
 provisioned the network in such a way that the Rendezvous Point (RP)
 for a particular ASM group G is always between the receivers and the
 sources.  If the network is provisioned in this manner, the ingress
 Provider Edge (PE) for (S,G) is always the same as the ingress PE for
 the RP, and thus the Source Active auto-discovery (A-D) routes are
 never needed.  If it is known a priori that the network is
 provisioned in this manner, mLDP in-band signaling can be supported
 using a different set of procedures, as specified in [RFC7438].  A
 service provider will provision the PE routers to use either the
 procedures in [RFC7438] or those described in this document.

Rekhter, et al. Standards Track [Page 3] RFC 7442 PIM-SM over P2MP mLDP LSPs February 2015

 Like [RFC6826], 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 the control of the MPLS
 network operator, or if the number of LSPs for a particular service
 is known to be limited.
 It is to be noted that the existing BGP Multicast VPN (MVPN)
 procedures [RFC6514] can 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 for this document.
 This document assumes that a given LSR may have some interfaces that
 are IP multicast capable, while other interfaces would be MPLS
 capable.

1.1. 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].

2. Mechanism 1 - Non-transitive Mapping of IP Multicast Shared Trees

 This mechanism 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 (Mechanism 1)

 Whenever (as a result of receiving either PIM Register or Multicast
 Source Discovery Protocol (MSDP) messages) an RP discovers a new
 multicast source, the RP SHOULD originate a Source Active
 auto-discovery route.  The route carries a single MCAST-VPN Network
 Layer Reachability Information (NLRI) [RFC6514], constructed as
 follows:
 + The Route Distinguisher (RD) in this NLRI is set to 0.
 + The Multicast Source field is set to S.  This could be either an
   IPv4 or an IPv6 address.  The Multicast Source Length field is set
   appropriately to reflect the address type.

Rekhter, et al. Standards Track [Page 4] RFC 7442 PIM-SM over P2MP mLDP LSPs February 2015

 + The Multicast Group field is set to G.  This could be either an
   IPv4 or an IPv6 address.  The Multicast Group Length field is set
   appropriately to reflect this address type.
 To constrain distribution of the Source Active auto-discovery route
 to the Autonomous System (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 previously advertised by the RP.

2.2. Receiving Source Active Auto-discovery Routes 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, an LSR creates in its Tree Information Base
 (TIB) a new (*,G) entry with a non-empty outgoing interface list that
 contains one or more IP multicast interfaces, the LSR MUST check to
 see 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
 [RFC6826].
 When an LSR receives a new Source Active auto-discovery route, the
 LSR MUST check to see if its TIB contains a (*,G) entry with the same
 G as that 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 [RFC6826].

2.3. Handling (S,G,RPT-bit) State

 The creation and deletion of (S,G,RPT-bit) PIM state ([RFC4601]) on
 an LSR that resulted from receiving PIM messages on one of its IP
 multicast interfaces do not result in any mLDP and/or BGP actions by
 the LSR.

Rekhter, et al. Standards Track [Page 5] RFC 7442 PIM-SM over P2MP mLDP LSPs February 2015

3. Mechanism 2 - Transitive Mapping of IP Multicast Shared Trees

 This mechanism 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 propagates this state in mLDP, as described below.
 Note that in the deployment scenarios where, for a given G, none of
 the PEs originate an (S,G) mLDP Label Map with the Transit IPv4/IPv6
 Source TLV, no Source Active auto-discovery routes will be used.  One
 other scenario where no Source Active auto-discovery routes will be
 used is described in Section 3.2 ("Originating Source Active
 Auto-discovery Routes (Mechanism 2)").  In all of these scenarios,
 the only part of Mechanism 2 that is used is the in-band signaling
 for IP Multicast Shared Trees, as described in the next section.

3.1. In-Band Signaling for IP Multicast Shared Trees

 To provide support for in-band mLDP signaling of IP multicast shared
 trees, this document defines two new mLDP TLVs: the Transit IPv4
 Shared Tree TLV and the Transit IPv6 Shared Tree TLV.
 These two TLVs have exactly the same encoding/format as the IPv4/IPv6
 Source Tree TLVs defined in [RFC6826], except that instead of the
 Source field they have an RP field that carries the address of the
 RP, as follows:
    Transit IPv4 Shared Tree TLV:
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Type          | Length                        | RP            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                               | Group         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      Type:  11
      Length:  8
      RP:  IPv4 RP address, 4 octets.
      Group:  IPv4 multicast group address, 4 octets.

Rekhter, et al. Standards Track [Page 6] RFC 7442 PIM-SM over P2MP mLDP LSPs February 2015

    Transit IPv6 Shared Tree TLV:
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Type          | Length                        | RP            ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~                                               | Group         ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      Type:  12
      Length:  32
      RP:  IPv6 RP address, 16 octets.
      Group:  IPv6 multicast group address, 16 octets.
 Procedures for in-band signaling for IP multicast shared trees with
 mLDP follow the same procedures as those for in-band signaling for
 IP multicast source trees, as specified in [RFC6826], except that
 while the latter signals (S,G) state using Transit IPv4/IPv6 Source
 TLVs, the former signals (*,G) state using Transit IPv4/IPv6 Shared
 Tree TLVs.

3.2. Originating Source Active Auto-discovery Routes (Mechanism 2)

 Consider an LSR that has some of its interfaces capable of IP
 multicast and some capable of MPLS multicast.
 Whenever such an 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),
 the LSR MUST originate a Source Active auto-discovery route if all of
 the following are true:
 + S is reachable via one of the IP-multicast-capable interfaces,
 + the LSR determines that G is in the PIM-SM in ASM mode range, and
 + the LSR does not have a (*,G) state with one of the IP-multicast-
   capable interfaces as an incoming interface (iif) for that state.

Rekhter, et al. Standards Track [Page 7] RFC 7442 PIM-SM over P2MP mLDP LSPs February 2015

 The route carries a single MCAST-VPN NLRI, constructed as follows:
 + The RD in this NLRI is set to 0.
 + The Multicast Source field is set to S.  The Multicast Source
   Length field is set appropriately to reflect this address type.
 + The Multicast Group field is set to G.  The Multicast Group Length
   field is set appropriately to reflect this address type.
 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 receiving an mLDP Label Map with the Transit
 IPv4/IPv6 Source TLV for (S,G) deletes the (S,G) state that was
 previously created, 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.
 Note that whenever an 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) with S reachable via one of the IP-multicast-capable
 interfaces, and the LSR already has a (*,G) state with the RP
 reachable via one of the IP-multicast-capable interfaces as a result
 of receiving an mLDP Label Map with the Transit IPv4/IPv6 Shared Tree
 TLV for (*,G), the LSR does not originate a Source Active
 auto-discovery route.

3.3. Receiving Source Active Auto-discovery Routes

 Procedures for receiving Source Active auto-discovery routes are the
 same as those for Mechanism 1.

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 (iif) list for that entry contains one of
 the IP interfaces, (c) at least one of the MPLS interfaces is in the
 outgoing interface (oif) list 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-bit) downstream state to the Prune state.  (Conceptually,
 the PIM state machine on the LSR will act "as if" it had received

Rekhter, et al. Standards Track [Page 8] RFC 7442 PIM-SM over P2MP mLDP LSPs February 2015

 Prune(S,G,rpt) on one of its MPLS interfaces, without actually having
 received one.)  Depending on the (S,G,RPT-bit) 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-bit) downstream state machine in the
 Prune state for as long as (a) the outgoing interface (oif) list for
 (*,G) contains one of the MPLS interfaces, (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 one or more of these conditions
 become no longer valid, the LSR MUST transition the (S,G,RPT-bit)
 downstream state machine to the NoInfo state.
 Note that except for the scenario described in the first paragraph of
 this section, it is sufficient to rely solely on the PIM procedures
 on the LSR to ensure the correct behavior when pruning sources off
 the shared tree.

3.5. More on Handling (S,G,RPT-bit) State

 The creation and deletion of (S,G,RPT-bit) state on an LSR that
 resulted from receiving PIM messages on one of its IP multicast
 interfaces do not result in any mLDP and/or BGP actions by the LSR.

4. IANA Considerations

 IANA maintains a registry called "Label Distribution Protocol (LDP)
 Parameters" with a subregistry called "LDP MP Opaque Value Element
 basic type".  IANA has allocated two new values, as follows:
    Value | Name                         | Reference
    ------+------------------------------+------------
      11  | Transit IPv4 Shared Tree TLV | [RFC7442]
      12  | Transit IPv6 Shared Tree TLV | [RFC7442]

5. Security Considerations

 All of the security considerations for mLDP ([RFC6388]) apply here.
 From the security considerations point of view, the use of Shared
 Tree TLVs is no different than the use of Source TLVs [RFC6826].

Rekhter, et al. Standards Track [Page 9] RFC 7442 PIM-SM over P2MP mLDP LSPs February 2015

6. References

6.1. Normative References

 [RFC1997]  Chandra, R., Traina, P., and T. Li, "BGP Communities
            Attribute", RFC 1997, August 1996,
            <http://www.rfc-editor.org/info/rfc1997>.
 [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
            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,
            "Protocol Independent Multicast - Sparse Mode (PIM-SM):
            Protocol Specification (Revised)", RFC 4601, August 2006,
            <http://www.rfc-editor.org/info/rfc4601>.
 [RFC6388]  Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B.
            Thomas, "Label Distribution Protocol Extensions for Point-
            to-Multipoint and Multipoint-to-Multipoint Label Switched
            Paths", RFC 6388, November 2011,
            <http://www.rfc-editor.org/info/rfc6388>.
 [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,
            <http://www.rfc-editor.org/info/rfc6514>.
 [RFC6826]  Wijnands, IJ., Ed., 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,
            <http://www.rfc-editor.org/info/rfc6826>.

6.2. Informative References

 [RFC4607]  Holbrook, H. and B. Cain, "Source-Specific Multicast for
            IP", RFC 4607, August 2006, <http://www.rfc-editor.org/
            info/rfc4607>.
 [RFC7438]  Wijnands, IJ., Ed., Rosen, E., Gulko, A., Joorde, U., and
            J.  Tantsura, "Multipoint LDP (mLDP) In-Band Signaling
            with Wildcards", RFC 7438, January 2015,
            <http://www.rfc-editor.org/info/rfc7438>.

Rekhter, et al. Standards Track [Page 10] RFC 7442 PIM-SM over P2MP mLDP LSPs February 2015

Acknowledgements

 The use of Source Active auto-discovery routes was borrowed from
 [RFC6514].  Some text in this document was borrowed from [RFC6514].
 Some of the text in this document was borrowed from [RFC6826].
 We would like to acknowledge Arkadiy Gulko for his review and
 comments.
 We would also like to thank Xuxiaohu, Gregory Mirsky, Rajiv Asati,
 and Adrian Farrel for their review and comments.

Authors' Addresses

 Yakov Rekhter
 Juniper Networks, Inc.
 EMail: yakov@juniper.net
 Rahul Aggarwal
 Arktan
 EMail: raggarwa_1@yahoo.com
 Nicolai Leymann
 Deutsche Telekom
 Winterfeldtstrasse 21
 Berlin  10781
 Germany
 EMail: N.Leymann@telekom.de
 Wim Henderickx
 Alcatel-Lucent
 EMail: wim.henderickx@alcatel-lucent.com
 Quintin Zhao
 Huawei
 EMail: quintin.zhao@huawei.com
 Richard Li
 Huawei
 EMail: renwei.li@huawei.com

Rekhter, et al. Standards Track [Page 11]

/data/webs/external/dokuwiki/data/pages/rfc/rfc7442.txt · Last modified: 2015/02/03 05:19 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki