draft-ietf-mpls-pim-sm-over-mldp-03.txt   rfc7442.txt 
Network Working Group Yakov Rekhter Internet Engineering Task Force (IETF) Y. Rekhter
Internet Draft Juniper Networks Request for Comments: 7442 Juniper Networks
Intended status: Standards Track Category: Standards Track R. Aggarwal
Expires: May 2015 Rahul Aggarwal ISSN: 2070-1721 Arktan
Arktan N. Leymann
Nicolai Leymann
Deutsche Telekom Deutsche Telekom
W. Henderickx
Wim Henderickx
Alcatel-Lucent Alcatel-Lucent
Q. Zhao
Quintin Zhao R. Li
Huawei
Richard Li
Huawei Huawei
February 2015
November 28, 2014 Carrying Protocol Independent Multicast - Sparse Mode (PIM-SM)
in Any-Source Multicast (ASM) Mode Trees over Multipoint LDP (mLDP)
Carrying PIM-SM in ASM mode Trees over P2MP mLDP LSPs
draft-ietf-mpls-pim-sm-over-mldp-03.txt
Status of this Memo Abstract
This Internet-Draft is submitted to IETF in full conformance with the When IP multicast trees created by Protocol Independent Multicast -
provisions of BCP 78 and BCP 79. 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).
Internet-Drafts are working documents of the Internet Engineering Status of This Memo
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 This is an Internet Standards Track document.
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 This document is a product of the Internet Engineering Task Force
http://www.ietf.org/ietf/1id-abstracts.txt. (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.
The list of Internet-Draft Shadow Directories can be accessed at Information about the current status of this document, any errata,
http://www.ietf.org/shadow.html. and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7442.
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.
Abstract
When IP multicast trees created by 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. This
document describes how to accomplish this in the case where such
Point-to-Multipoint Label Switched Paths are established using Label
Distribution Protocol Extensions for Point-to-Multipoint and
Multipoint-to-Multipoint Label Switched Paths Multipoint LDP (mLDP).
Table of Contents Table of Contents
1 Introduction ................................................. 3 1. Introduction ....................................................3
1.1 Specification of Requirements ................................ 5 1.1. Specification of Requirements ..............................4
2 Mechanism 1 - Non-transitive Mapping of IP Multicast Shared Trees 5 2. Mechanism 1 - Non-transitive Mapping of IP Multicast
2.1 Originating Source Active Auto-Discovery Routes (Mechanism 1) .. 5 Shared Trees ....................................................4
2.2 Receiving Source Active Auto-Discovery Route by LSR .......... 6 2.1. Originating Source Active Auto-discovery Routes
2.3 Handling (S, G, RPT-bit) State ............................... 6 (Mechanism 1) ..............................................4
3 Mechanism 2 - Transitive Mapping of IP Multicast Shared Tree ... 6 2.2. Receiving Source Active Auto-discovery Routes by LSR .......5
3.1 In-band Signaling for IP Multicast Shared Trees .............. 7 2.3. Handling (S,G,RPT-bit) State ...............................5
3.2 Originating Source Active Auto-Discovery Routes (Mechanism 2) .. 8 3. Mechanism 2 - Transitive Mapping of IP Multicast Shared Trees ...6
3.3 Receiving Source Active Auto-Discovery Route ................. 9 3.1. In-Band Signaling for IP Multicast Shared Trees ............6
3.4 Pruning Sources Off the Shared Tree .......................... 9 3.2. Originating Source Active Auto-discovery Routes
3.5 More on Handling (S,G,RPT-bit) State ......................... 10 (Mechanism 2) ..............................................7
4 IANA Considerations .......................................... 10 3.3. Receiving Source Active Auto-discovery Routes ..............8
5 Security Considerations ...................................... 10 3.4. Pruning Sources Off the Shared Tree ........................8
6 Acknowledgements ............................................. 10 3.5. More on Handling (S,G,RPT-bit) State .......................9
7 Normative References ......................................... 11 4. IANA Considerations .............................................9
8 Informative References ....................................... 11 5. Security Considerations .........................................9
9 Authors' Addresses ........................................... 11 6. References .....................................................10
6.1. Normative References ......................................10
6.2. Informative References ....................................10
Acknowledgements ..................................................11
Authors' Addresses ................................................11
1. Introduction 1. Introduction
[RFC6826] describes how to map Point-to-Multipoint Label Switched [RFC6826] describes how to map Point-to-Multipoint Label Switched
Paths (P2MP LSPs) created by mLDP [RFC6388] to multicast trees Paths (P2MP LSPs) created by mLDP [RFC6388] to multicast trees
created by PIM-SM in Source-Specific Multicast (SSM) mode [RFC4607]. created by Protocol Independent Multicast - Sparse Mode (PIM-SM) in
This document describes how to map mLDP P2MP trees to multicast trees Source-Specific Multicast (SSM) mode [RFC4607]. This document
created by PIM-SM in Any-Source Multicast (ASM) mode. It describes describes how to map mLDP P2MP trees to multicast trees created by
two possible mechanisms for doing this. 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 The first mechanism, described in Section 2, is OPTIONAL for
implementations, but the second mechanism, described in Section 3, is implementations, but the second mechanism, described in Section 3, is
REQUIRED for all implementations claiming conformance to this REQUIRED for all implementations claiming conformance to this
specification. specification.
Note that from a deployment point of view these two mechanisms are Note that from a deployment point of view these two mechanisms are
mutually exclusive. That is on the same network one could deploy mutually exclusive. That is, on the same network one could deploy
either one of the mechanisms, but not both. either one of the mechanisms, but not both.
The reader of this document is expected to be familiar with PIM-SM The reader of this document is expected to be familiar with PIM-SM
[RFC4601] and mLDP [RFC6388]. [RFC4601] and mLDP [RFC6388].
This document relies on the procedures in [RFC6826] to support Source This document relies on the procedures in [RFC6826] to support source
Trees. E.g., following these procedures a Label Switching Router trees. For example, following these procedures a Label Switching
(LSR) may initiate an mLDP Label Map with the Transit IPv4/IPv6 Router (LSR) may initiate an mLDP Label Map with the Transit
Source TLV for (S, G) when receiving a PIM (S,G) Join. IPv4/IPv6 Source TLV for (S,G) when receiving a PIM (S,G) Join.
This document uses BGP Source Active auto-discovery routes, as This document uses BGP Source Active auto-discovery routes, as
defined in [RFC6514]. For the sake of brevity in the rest of the 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- document, we'll refer to these routes as just "Source Active
discovery routes". auto-discovery routes".
Consider a deployment scenario where the service provider has Consider a deployment scenario where the service provider has
provisioned the network in such a way that the Rendezvous Point (RP) 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 for a particular ASM group G is always between the receivers and the
sources. If the network is provisioned in this manner, the ingress PE sources. If the network is provisioned in this manner, the ingress
for (S,G) is always the same as the ingress PE for the RP, and thus Provider Edge (PE) for (S,G) is always the same as the ingress PE for
the Source Active auto-discovery (A-D) routes are never needed. If it the RP, and thus the Source Active auto-discovery (A-D) routes are
is known a priori that the network is provisioned in this manner, never needed. If it is known a priori that the network is
mLDP in-band signaling can be supported using a different set of provisioned in this manner, mLDP in-band signaling can be supported
procedures, as specified in [draft-wijnands]. A service provider will using a different set of procedures, as specified in [RFC7438]. A
provision the PE routers either to use [draft-wijnands] procedures or service provider will provision the PE routers to use either the
to use the procedures of this document. procedures in [RFC7438] or those described in this document.
Like [RFC6826], each IP multicast tree is mapped one-to-one to a P2MP 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 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 number of LSPs that are created is under the control of the MPLS
operator, or if the number of LSPs for a particular service is known network operator, or if the number of LSPs for a particular service
to be limited. is known to be limited.
It is to be noted that the existing BGP Multicast VPN (MVPN) It is to be noted that the existing BGP Multicast VPN (MVPN)
procedures [RFC6514] can be used to map Internet IP multicast trees procedures [RFC6514] can be used to map Internet IP multicast trees
to P2MP LSPs. These procedures would accomplish this for IP 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 SSM mode, as well as for IP
multicast trees created by PIM-SM in ASM mode. Furthermore, these multicast trees created by PIM-SM in ASM mode. Furthermore, these
procedures would also support the ability to aggregate multiple IP procedures would also support the ability to aggregate multiple IP
multicast trees to one P2MP LSP in the MPLS network. The details of multicast trees to one P2MP LSP in the MPLS network. The details of
this particular approach are out of scope of this document. this particular approach are out of scope for this document.
This document assumes that a given LSR may have some of its This document assumes that a given LSR may have some interfaces that
interfaces IP multicast capable, while other interfaces being MPLS are IP multicast capable, while other interfaces would be MPLS
capable. capable.
1.1. Specification of Requirements 1.1. Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2. Mechanism 1 - Non-transitive Mapping of IP Multicast Shared Trees 2. Mechanism 1 - Non-transitive Mapping of IP Multicast Shared Trees
This mechanism does not transit IP multicast shared trees over the This mechanism does not transit IP multicast shared trees over the
MPLS network. Therefore, when an LSR creates (*, G) state (as a MPLS network. Therefore, when an LSR creates (*,G) state (as a
result of receiving PIM messages on one of its IP multicast result of receiving PIM messages on one of its IP multicast
interfaces), the LSR does not propagate this state in mLDP. interfaces), the LSR does not propagate this state in mLDP.
2.1. Originating Source Active Auto-Discovery Routes (Mechanism 1) 2.1. Originating Source Active Auto-discovery Routes (Mechanism 1)
Whenever (as a result of receiving either PIM Register or MSDP Whenever (as a result of receiving either PIM Register or Multicast
messages) an RP discovers a new multicast source, the RP SHOULD Source Discovery Protocol (MSDP) messages) an RP discovers a new
originate a Source Active auto-discovery route. The route carries a multicast source, the RP SHOULD originate a Source Active
single MCAST-VPN Network Layer Reachability Information (NLRI) auto-discovery route. The route carries a single MCAST-VPN Network
[RFC6514] constructed as follows: Layer Reachability Information (NLRI) [RFC6514], constructed as
follows:
+ The Route Distinguisher (RD) in this NLRI is set to 0. + The Route Distinguisher (RD) in this NLRI is set to 0.
+ The Multicast Source field is set to S. This could be either an + 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 IPv4 or an IPv6 address. The Multicast Source Length field is set
appropriately to reflect the address type. appropriately to reflect the address type.
+ The Multicast Group field is set to G. This could be either an + 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 IPv4 or an IPv6 address. The Multicast Group Length field is set
appropriately to reflect this address type. appropriately to reflect this address type.
To constrain distribution of the Source Active auto-discovery route To constrain distribution of the Source Active auto-discovery route
to the AS of the advertising RP this route SHOULD carry the NO_EXPORT to the Autonomous System (AS) of the advertising RP, this route
Community ([RFC1997]). SHOULD carry the NO_EXPORT Community ([RFC1997]).
Using the normal BGP procedures the Source Active auto-discovery Using the normal BGP procedures, the Source Active auto-discovery
route is propagated to all other LSRs within the AS. route is propagated to all other LSRs within the AS.
Whenever the RP discovers that the source is no longer active, the RP 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 MUST withdraw the Source Active auto-discovery route if such a route
was previously advertised by the RP. was previously advertised by the RP.
2.2. Receiving Source Active Auto-Discovery Route by LSR 2.2. Receiving Source Active Auto-discovery Routes by LSR
Consider an LSR that has some of its interfaces capable of IP Consider an LSR that has some of its interfaces capable of IP
multicast and some capable of MPLS multicast. multicast and some capable of MPLS multicast.
When as a result of receiving PIM messages on one of its IP multicast When, as a result of receiving PIM messages on one of its IP
interfaces an LSR creates in its Tree Information Base (TIB) a new multicast interfaces, an LSR creates in its Tree Information Base
(*, G) entry with a non-empty outgoing interface list that contains (TIB) a new (*,G) entry with a non-empty outgoing interface list that
one or more IP multicast interfaces, the LSR MUST check if it has any contains one or more IP multicast interfaces, the LSR MUST check to
Source Active auto-discovery routes for that G. If there is such a see if it has any Source Active auto-discovery routes for that G. If
route, S of that route is reachable via an MPLS interface, and the there is such a route, S of that route is reachable via an MPLS
LSR does not have (S, G) state in its TIB for (S, G) carried in the interface, and the LSR does not have (S,G) state in its TIB for (S,G)
route, then the LSR originates the mLDP Label Map with the Transit carried in the route, then the LSR originates the mLDP Label Map with
IPv4/IPv6 Source TLV carrying (S,G), as specified in [RFC6826]. 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 When an LSR receives a new Source Active auto-discovery route, the
LSR MUST check if its TIB contains a (*, G) entry with the same G as LSR MUST check to see if its TIB contains a (*,G) entry with the same
carried in the Source Active auto-discovery route. If such an entry G as that carried in the Source Active auto-discovery route. If such
is found, S is reachable via an MPLS interface, and the LSR does not an entry is found, S is reachable via an MPLS interface, and the LSR
have (S, G) state in its TIB for (S, G) carried in the route, then does not have (S,G) state in its TIB for (S,G) carried in the route,
the LSR originates an mLDP Label Map with the Transit IPv4/IPv6 then the LSR originates an mLDP Label Map with the Transit IPv4/IPv6
Source TLV carrying (S,G), as specified in [RFC6826]. Source TLV carrying (S,G), as specified in [RFC6826].
2.3. Handling (S, G, RPT-bit) State 2.3. Handling (S,G,RPT-bit) State
Creation and deletion of (S, G, RPT-bit) PIM state ([RFC4601]) on an The creation and deletion of (S,G,RPT-bit) PIM state ([RFC4601]) on
LSR that resulted from receiving PIM messages on one of its IP an LSR that resulted from receiving PIM messages on one of its IP
multicast interfaces does not result in any mLDP and/or BGP actions multicast interfaces do not result in any mLDP and/or BGP actions by
by the LSR. the LSR.
3. Mechanism 2 - Transitive Mapping of IP Multicast Shared Tree 3. Mechanism 2 - Transitive Mapping of IP Multicast Shared Trees
This mechanism enables transit of IP multicast shared trees over the This mechanism enables transit of IP multicast shared trees over the
MPLS network. Therefore, when an LSR creates (*, G) state as a result MPLS network. Therefore, when an LSR creates (*,G) state as a result
of receiving PIM messages on one of its IP multicast interfaces, the of receiving PIM messages on one of its IP multicast interfaces, the
LSR propagates this state in mLDP, as described below. LSR propagates this state in mLDP, as described below.
Note that in the deployment scenarios where for a given G none of the Note that in the deployment scenarios where, for a given G, none of
PEs originate an (S, G) mLDP Label Map with the Transit IPv4/IPv6 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 Source TLV, no Source Active auto-discovery routes will be used. One
other scenario where no Source Active auto-discovery routes will be other scenario where no Source Active auto-discovery routes will be
used is described in section "Originating Source Active Auto- used is described in Section 3.2 ("Originating Source Active
Discovery Routes (Mechanism 2)". In all these scenarios the only part Auto-discovery Routes (Mechanism 2)"). In all of these scenarios,
of Mechanism 2 that is used is the in-band signaling for IP Multicast the only part of Mechanism 2 that is used is the in-band signaling
Shared Trees, as described in the next section. for IP Multicast Shared Trees, as described in the next section.
3.1. In-band Signaling for IP Multicast Shared Trees 3.1. In-Band Signaling for IP Multicast Shared Trees
To provide support for in-band mLDP signaling of IP multicast shared To provide support for in-band mLDP signaling of IP multicast shared
trees this document defines two new mLDP TLVs: Transit IPv4 Shared trees, this document defines two new mLDP TLVs: the Transit IPv4
Tree TLV, and Transit IPv6 Shared Tree TLV. Shared Tree TLV and the Transit IPv6 Shared Tree TLV.
These two TLVs have exactly the same encoding/format as the IPv4/IPv6 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 Tree TLVs defined in [RFC6826], except that instead of the
Source field they have an RP field that carries the address of the Source field they have an RP field that carries the address of the
RP, as follows: RP, as follows:
Transit IPv4 Shared Tree TLV: Transit IPv4 Shared Tree TLV:
0 1 2 3 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 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 | | Type | Length | RP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Group | | | Group |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: TBD1 (to be assigned by IANA). Type: 11
Length: 8 Length: 8
RP: IPv4 RP address, 4 octets. RP: IPv4 RP address, 4 octets.
Group: IPv4 multicast group address, 4 octets. Group: IPv4 multicast group address, 4 octets.
Transit IPv6 Shared Tree TLV: Transit IPv6 Shared Tree TLV:
0 1 2 3 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 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 ~ | Type | Length | RP ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ | Group ~ ~ | Group ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ | ~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: TBD2 (to be assigned by IANA). Type: 12
Length: 32 Length: 32
RP: IPv6 RP address, 16 octets. RP: IPv6 RP address, 16 octets.
Group: IPv6 multicast group address, 16 octets. Group: IPv6 multicast group address, 16 octets.
Procedures for in-band signaling for IP multicast shared trees with Procedures for in-band signaling for IP multicast shared trees with
mLDP follow the same procedures as for in-band signaling for IP mLDP follow the same procedures as those for in-band signaling for
multicast source trees specified in [RFC6826], except that while the IP multicast source trees, as specified in [RFC6826], except that
latter signals (S,G) state using Transit IPv4/IPv6 Source TLVs, the while the latter signals (S,G) state using Transit IPv4/IPv6 Source
former signals (*,G) state using Transit IPv4/IPv6 Shared Tree TLVs. TLVs, the former signals (*,G) state using Transit IPv4/IPv6 Shared
Tree TLVs.
3.2. Originating Source Active Auto-Discovery Routes (Mechanism 2) 3.2. Originating Source Active Auto-discovery Routes (Mechanism 2)
Consider an LSR that has some of its interfaces capable of IP Consider an LSR that has some of its interfaces capable of IP
multicast and some capable of MPLS multicast. multicast and some capable of MPLS multicast.
Whenever such an LSR creates an (S, G) state as a result of receiving 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) 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 LSR MUST originate a Source Active auto-discovery route if all of
the following are true: the following are true:
+ S is reachable via one of the IP multicast capable interfaces, + 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 determines that G is in the PIM-SM in ASM mode range, and
+ the LSR does not have an (*, G) state with one of the IP + the LSR does not have a (*,G) state with one of the IP-multicast-
multicast capable interfaces as an incoming interface (iif) for capable interfaces as an incoming interface (iif) for that state.
that state.
The route carries a single MCAST-VPN NLRI constructed as follows: The route carries a single MCAST-VPN NLRI, constructed as follows:
+ The RD in this NLRI is set to 0. + The RD in this NLRI is set to 0.
+ The Multicast Source field is set to S. The Multicast Source + The Multicast Source field is set to S. The Multicast Source
Length field is set appropriately to reflect this address type. Length field is set appropriately to reflect this address type.
+ The Multicast Group field is set to G. The Multicast Group Length + The Multicast Group field is set to G. The Multicast Group Length
field is set appropriately to reflect this address type. field is set appropriately to reflect this address type.
To constrain distribution of the Source Active auto-discovery route To constrain distribution of the Source Active auto-discovery route
to the AS of the advertising LSR this route SHOULD carry the to the AS of the advertising LSR, this route SHOULD carry the
NO_EXPORT Community ([RFC1997]). NO_EXPORT Community ([RFC1997]).
Using the normal BGP procedures the Source Active auto-discovery Using the normal BGP procedures, the Source Active auto-discovery
route is propagated to all other LSRs within the AS. route is propagated to all other LSRs within the AS.
Whenever the LSR receiving an mLDP Label Map with the Transit 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 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 previously created, the LSR that deletes the state MUST also withdraw
the Source Active auto-discovery route, if such a route was the Source Active auto-discovery route, if such a route was
advertised when the state was created. advertised when the state was created.
Note that whenever an LSR creates an (S,G) state as a result of 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 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 (S,G) with S reachable via one of the IP-multicast-capable
interfaces, and the LSR already has a (*,G) state with RP reachable interfaces, and the LSR already has a (*,G) state with the RP
via one of the IP multicast capable interfaces as a result of reachable via one of the IP-multicast-capable interfaces as a result
receiving an mLDP Label Map with the Transit IPv4/IPv6 Shared Tree 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- TLV for (*,G), the LSR does not originate a Source Active
discovery route. auto-discovery route.
3.3. Receiving Source Active Auto-Discovery Route 3.3. Receiving Source Active Auto-discovery Routes
Procedures for receiving Source Active Auto-Discovery routes are the Procedures for receiving Source Active auto-discovery routes are the
same as with Mechanism 1. same as those for Mechanism 1.
3.4. Pruning Sources Off the Shared Tree 3.4. Pruning Sources Off the Shared Tree
If after receiving a new Source Active auto-discovery route for (S,G) If, after receiving a new Source Active auto-discovery route for
the LSR determines that (a) it has the (*, G) entry in its TIB, (b) (S,G), the LSR determines that (a) it has the (*,G) entry in its TIB,
the incoming interface list (iif) for that entry contains one of the (b) the incoming interface (iif) list for that entry contains one of
IP interfaces, (c) at least one of the MPLS interfaces is in the 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 outgoing interface (oif) list for that entry, and (d) the LSR does
not originate an mLDP Label Mapping message for (S,G) with the not originate an mLDP Label Mapping message for (S,G) with the
Transit IPv4/IPv6 Source TLV, then the LSR MUST transition the Transit IPv4/IPv6 Source TLV, then the LSR MUST transition the
(S,G,RPT-bit) downstream state to the Prune state. (Conceptually the (S,G,RPT-bit) downstream state to the Prune state. (Conceptually,
PIM state machine on the LSR will act "as if" it had received 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 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 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 may result in the LSR using PIM procedures to prune S off the Shared
(*,G) tree. (*,G) tree.
The LSR MUST keep the (S,G,RPT-bit) downstream state machine in the The LSR MUST keep the (S,G,RPT-bit) downstream state machine in the
Prune state for as long as (a) the outgoing interface list (oif) for Prune state for as long as (a) the outgoing interface (oif) list for
(*, G) contains one of the MPLS interfaces, and (b) the LSR has at (*,G) contains one of the MPLS interfaces, (b) the LSR has at least
least one Source Active auto-discovery route for (S,G), and (c) the one Source Active auto-discovery route for (S,G), and (c) the LSR
LSR does not originate the mLDP Label Mapping message for (S,G) with does not originate the mLDP Label Mapping message for (S,G) with the
the Transit IPv4/IPv6 Source TLV. Once either of these conditions 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) become no longer valid, the LSR MUST transition the (S,G,RPT-bit)
downstream state machine to the NoInfo state. downstream state machine to the NoInfo state.
Note that except for the scenario described in the first paragraph of Note that except for the scenario described in the first paragraph of
this section, it is sufficient to rely solely on the PIM procedures this section, it is sufficient to rely solely on the PIM procedures
on the LSR to ensure the correct behavior when pruning sources off on the LSR to ensure the correct behavior when pruning sources off
the shared tree. the shared tree.
3.5. More on Handling (S,G,RPT-bit) State 3.5. More on Handling (S,G,RPT-bit) State
Creation and deletion of (S,G,RPT-bit) state on a LSR that resulted The creation and deletion of (S,G,RPT-bit) state on an LSR that
from receiving PIM messages on one of its IP multicast interfaces resulted from receiving PIM messages on one of its IP multicast
does not result in any mLDP and/or BGP actions by the LSR. interfaces do not result in any mLDP and/or BGP actions by the LSR.
4. IANA Considerations 4. IANA Considerations
IANA maintains a registry called "Label Distribution Protocol (LDP) IANA maintains a registry called "Label Distribution Protocol (LDP)
Parameters" with a subregistry called "LDP MP Opaque Value Element Parameters" with a subregistry called "LDP MP Opaque Value Element
basic type". IANA is requested to allocate two new values as follows: basic type". IANA has allocated two new values, as follows:
Value | Name | Reference Value | Name | Reference
------+------------------------------+------------ ------+------------------------------+------------
TBD1 | Transit IPv4 Shared Tree TLV | [This.I-D] 11 | Transit IPv4 Shared Tree TLV | [RFC7442]
TBD2 | Transit IPv6 Shared Tree TLV | [This.I-D] 12 | Transit IPv6 Shared Tree TLV | [RFC7442]
IANA is requested to assign consecutive values. 5. Security Considerations
5. Security Considerations All of the security considerations for mLDP ([RFC6388]) apply here.
All 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].
From the security considerations point of view use of Shared Tree 6. References
TLVs is no different than use of Source TLVs [RFC6826].
6. Acknowledgements 6.1. Normative References
Use of Source Active auto-discovery routes was borrowed from [RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities
[RFC6514]. Some text in this document was borrowed from [RFC6514]. Attribute", RFC 1997, August 1996,
<http://www.rfc-editor.org/info/rfc1997>.
Some of the text in this document was borrowed from [RFC6826]. [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>.
We would like to acknowledge Arkadiy Gulko for his review and [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
comments. "Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601, August 2006,
<http://www.rfc-editor.org/info/rfc4601>.
We would also like to thank Xuxiaohu, Gregory Mirsky, Rajiv Asati, [RFC6388] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B.
and Adrian Farrell for their review and comments. 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>.
7. Normative References [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>.
[RFC1997] R. Chandra, P. Traina, T. Li, "BGP Communities Attribute", [RFC6826] Wijnands, IJ., Ed., Eckert, T., Leymann, N., and M.
RFC1997, August 1996. 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>.
[RFC2119] "Key words for use in RFCs to Indicate Requirement 6.2. Informative References
Levels.", Bradner, RFC2119, March 1997.
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for
"Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol IP", RFC 4607, August 2006, <http://www.rfc-editor.org/
Specification (Revised)", RFC 4601, August 2006. info/rfc4607>.
[RFC6388] Minei, I., "Label Distribution Protocol Extensions for [RFC7438] Wijnands, IJ., Ed., Rosen, E., Gulko, A., Joorde, U., and
Point-to-Multipoint and Multipoint-to-Multipoint Label Switched J. Tantsura, "Multipoint LDP (mLDP) In-Band Signaling
Paths", RFC6388, November 2011. with Wildcards", RFC 7438, January 2015,
<http://www.rfc-editor.org/info/rfc7438>.
[RFC6514] "BGP Encodings and Procedures for Multicast in MPLS/BGP IP Acknowledgements
VPNs", R. Aggarwal et al., RFC6514, February 2012
[RFC6826] "In-band signaling for Point-to-Multipoint and Multipoint- The use of Source Active auto-discovery routes was borrowed from
to-Multipoint Label Switched Paths", I. Wijnands et al., RFC6826, [RFC6514]. Some text in this document was borrowed from [RFC6514].
January 2013
8. Informative References Some of the text in this document was borrowed from [RFC6826].
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for We would like to acknowledge Arkadiy Gulko for his review and
IP", RFC 4607, August 2006. comments.
[draft-wijnands] Wijnands IJ, et. al., "mLDP In-Band Signaling with We would also like to thank Xuxiaohu, Gregory Mirsky, Rajiv Asati,
Wildcards", draft-ietf-mpls-mldp-in-band-wildcard-encoding, work in and Adrian Farrel for their review and comments.
progress
9. Authors' Addresses Authors' Addresses
Yakov Rekhter Yakov Rekhter
Juniper Networks, Inc. Juniper Networks, Inc.
e-mail: yakov@juniper.net EMail: yakov@juniper.net
Rahul Aggarwal Rahul Aggarwal
e-mail: raggarwa_1@yahoo.com Arktan
EMail: raggarwa_1@yahoo.com
Nicolai Leymann Nicolai Leymann
Deutsche Telekom Deutsche Telekom
Winterfeldtstrasse 21 Winterfeldtstrasse 21
Berlin 10781 Berlin 10781
Germany Germany
e-mail: nicolai.leymann@t-systems.com EMail: N.Leymann@telekom.de
Wim Henderickx Wim Henderickx
Alcatel-Lucent Alcatel-Lucent
Email: wim.henderickx@alcatel-lucent.com EMail: wim.henderickx@alcatel-lucent.com
Quintin Zhao Quintin Zhao
Huawei Huawei
Email: quintin.zhao@huawei.com EMail: quintin.zhao@huawei.com
Richard Li Richard Li
Huawei Huawei
Email: renwei.li@huawei.com EMail: renwei.li@huawei.com
 End of changes. 108 change blocks. 
258 lines changed or deleted 263 lines changed or added

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