draft-rekhter-mpls-pim-sm-over-mldp-06.txt   draft-rekhter-mpls-pim-sm-over-mldp-07.txt 
Network Working Group Yakov Rekhter Network Working Group Yakov Rekhter
Internet Draft Juniper Networks Internet Draft Juniper Networks
Intended status: Standards Track Intended status: Standards Track
Expires: February 2014 Rahul Aggarwal Expires: April 2014 Rahul Aggarwal
Arktan Arktan
Nicolai Leymann Nicolai Leymann
Deutsche Telekom Deutsche Telekom
Wim Henderickx Wim Henderickx
Alcatel-Lucent Alcatel-Lucent
Quintin Zhao Quintin Zhao
Huawei Huawei
Richard Li Richard Li
Huawei Huawei
August 29 2013 October 2 2013
Carrying PIM-SM in ASM mode Trees over P2MP mLDP LSPs Carrying PIM-SM in ASM mode Trees over P2MP mLDP LSPs
draft-rekhter-mpls-pim-sm-over-mldp-06.txt draft-rekhter-mpls-pim-sm-over-mldp-07.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 2, line 26 skipping to change at page 2, line 26
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 Abstract
When IP multicast trees created by PIM-SM in Any Source Multicast 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 (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 to map such trees to Point-to-Multipoint Label Switched Paths. This
document describes how to accomplish this in the case where such document describes how to accomplish this in the case where such
Point-to-Multipoint Label Switches Paths are established using mLDP. Point-to-Multipoint Label Switched Paths are established using mLDP.
Table of Contents Table of Contents
1 Specification of Requirements ......................... 3 1 Specification of Requirements ......................... 3
2 Introduction .......................................... 3 2 Introduction .......................................... 3
3 Option 1 .............................................. 4 3 Option 1 - Non-transitive mapping of IP multicast shared tree 5
3.1 Originating Source Active auto-discovery routes ....... 4 3.1 Originating Source Active auto-discovery routes (Option 1) 5
3.2 Receiving BGP Source Active auto-discovery route by LSR ...5 3.2 Receiving BGP Source Active auto-discovery route by LSR ...5
3.3 Handling (S, G, RPT-bit) state ........................ 6 3.3 Handling (S, G, RPT-bit) state ........................ 6
4 Option 2 .............................................. 6 4 Option 2 - Transitive mapping of IP multicast shared tree .6
4.1 In-band signaling for IP Multicast Shared Tree ........ 6 4.1 In-band signaling for IP Multicast Shared Tree ........ 6
4.2 Originating Source Active auto-discovery routes ....... 7 4.2 Originating Source Active auto-discovery routes (Option 2) 8
4.3 Receiving BGP Source Active auto-discovery route ...... 9 4.3 Receiving BGP Source Active auto-discovery route ...... 9
4.4 Pruning Sources off the Shared Tree ................... 9 4.4 Pruning Sources off the Shared Tree ................... 9
4.5 More on handling (S,G,RPT-bit) state .................. 9 4.5 More on handling (S,G,RPT-bit) state .................. 10
5 IANA Considerations ................................... 10 5 IANA Considerations ................................... 10
6 Security Considerations ............................... 10 6 Security Considerations ............................... 10
7 Acknowledgements ...................................... 10 7 Acknowledgements ...................................... 10
8 Normative References .................................. 10 8 Normative References .................................. 10
9 Non-normative References .............................. 11 9 Informative References ................................ 11
10 Authors' Addresses .................................... 11 10 Authors' Addresses .................................... 11
1. Specification of Requirements 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. Introduction 2. Introduction
[MLDP-IN-BAND-SIGNALLING] describes how to map Point-to-Multipoint [RFC6826] describes how to map Point-to-Multipoint Label Switched
Label Switched Paths (P2MP LSPs) created by mLDP [mLDP] to multicast Paths (P2MP LSPs) created by mLDP [mLDP] to multicast trees created
trees created by PIM-SM in SSM mode [RFC4607]. This document by PIM-SM in SSM mode [RFC4607]. This document describes how to map
describes how to map mLDP P2MP tress to multicast trees created by mLDP P2MP trees to multicast trees created by PIM-SM in ASM mode. It
PIM-SM in ASM mode. It describes two possible options for doing this. describes two possible options for doing this.
An implementation MAY support Option 1, as described in Section 3 of
this document. An implementation MUST support Option 2, as described
in Section 4 of this document.
Note that from a deployment point of view these two options are
mutually exclusive. That is on the same network one could either
deploy Option 1, or Option 2, 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 [mLDP]. [RFC4601] and mLDP [mLDP].
An implementation MAY support Option 1, as described in Section 2 of This document relies on the procedures in [RFC6826] to support Source
this document. An implementation MUST support Option 2, as described Trees. E.g., following these procedures an LSR may initiate a mLDP
in Section 3 of this document. Label Map with the Transit IPv4/IPv6 Source TLV for (S, G) when
receiving 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 [MVPN-BGP]. This document also identifies the deployment defined in [MVPN-BGP]. This document also identifies the deployment
scenarios where BGP Source Active auto-discovery routes will not be scenarios where BGP Source Active auto-discovery routes will not be
used. used.
Like [MLDP-IN-BAND-SIGNALLING], each IP multicast tree is mapped one- Like [RFC6826], each IP multicast tree is mapped one-to-one to a P2MP
to-one to a P2MP LSP in the MPLS network. This type of service works LSP in the MPLS network. This type of service works well if the
well if the number of LSPs that are created is under control of the number of LSPs that are created is under control of the MPLS network
MPLS network operator, or if the number of LSPs for a particular operator, or if the number of LSPs for a particular service are known
service are known to be limited in number. to be limited in number.
It is to be noted that the existing BGP MVPN [MVPN-BGP] procedures 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 may be used to map Internet IP multicast trees to P2MP LSPs. These
procedures would accomplish this for IP multicast trees created by 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- 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 SM in ASM mode. Furthermore, these procedures would also support the
ability to aggregate multiple IP multicast trees to one P2MP LSP in ability to aggregate multiple IP multicast trees to one P2MP LSP in
the MPLS network. The details of this particular approach are out of the MPLS network. The details of this particular approach are out of
scope of this document. scope of this document.
This document assumes that a given LSR may have some of its This document assumes that a given LSR may have some of its
interfaces IP multicast capable, while other interfaces being MPLS interfaces IP multicast capable, while other interfaces being MPLS
capable. This document further assumes that a given interface on an capable.
LSR is either IP multicast capable, or MPLS capable, but not both.
3. Option 1 3. Option 1 - Non-transitive mapping of IP multicast shared tree
This option does not transit IP multicast shared trees over the MPLS This option does not transit IP multicast shared trees over the MPLS
network. Therefore, when an LSR creates (*, G) state (as a result of network. Therefore, when an LSR creates (*, G) state (as a result of
receiving PIM messages on one of its IP multicast interfaces), the receiving PIM messages on one of its IP multicast interfaces), the
LSR does not propagate this state in mLDP. LSR does not propagate this state in mLDP.
3.1. Originating Source Active auto-discovery routes 3.1. Originating Source Active auto-discovery routes (Option 1)
Whenever (as a result of receiving either PIM Register or MSDP Whenever (as a result of receiving either PIM Register or MSDP
messages) a Rendezvous Point (RP) discovers a new multicast source, messages) a Rendezvous Point (RP) discovers a new multicast source,
the RP SHOULD originate a BGP Source Active auto-discovery route. the RP SHOULD originate a BGP Source Active auto-discovery route.
The route carries a single MCAST-VPN NLRI [MVPN-BGP] constructed as The route carries a single MCAST-VPN NLRI [MVPN-BGP] constructed as
follows: 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 MUST be set to S. This could be either + The Multicast Source field MUST be set to S. This could be either
skipping to change at page 5, line 39 skipping to change at page 6, line 8
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 multicast
interfaces such LSR creates in its Tree Information Base (TIB) a new interfaces such LSR creates in its Tree Information Base (TIB) a new
(*, G) entry with a non-empty outgoing interface list that contains (*, G) entry with a non-empty outgoing interface list that contains
one or more IP multicast interfaces, the LSR MUST check if it has any 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 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 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 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 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- IPv4/IPv6 Source TLV carrying (S,G), as specified in [RFC6826].
SIGNALLING].
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 an (*, G) entry with the same G as 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 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 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 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 the LSR originates an mLDP Label Map with the Transit IPv4/IPv6
Source TLV carrying (S,G), as specified in [MLDP-IN-BAND-SIGNALLING]. Source TLV carrying (S,G), as specified in [RFC6826].
3.3. Handling (S, G, RPT-bit) state 3.3. Handling (S, G, RPT-bit) state
Creation and deletion of (S, G, RPT-bit) PIM state ([RFC4601]) on a Creation and deletion of (S, G, RPT-bit) PIM state ([RFC4601]) on a
LSR that resulted from receiving PIM messages on one of its IP 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 does not result in any mLDP and/or BGP actions
by the LSR. by the LSR.
4. Option 2 4. Option 2 - Transitive mapping of IP multicast shared tree
This option enables transit of IP multicast shared trees over the This option 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 does propagate this state in mLDP, as described below. LSR does propagate 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 the
PEs originate an (S, G) mLDP Label Map with the Transit IPv4/IPv6 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 "Originating Source Active auto-
discovery routes". In all these scenarios the only part of Option 2 discovery routes (Option 2)". In all these scenarios the only part of
that will be used is the in-band signaling for IP Multicast Shared Option 2 that will be used is the in-band signaling for IP Multicast
Tree, as described in the next section. Shared Tree, as described in the next section.
4.1. In-band signaling for IP Multicast Shared Tree 4.1. In-band signaling for IP Multicast Shared Tree
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: Transit IPv4 Shared
Tree TLV, and Transit IPv6 Shared Tree TLV. Tree TLV, and 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 [MLDP-IN-BAND-SIGNALLING], except that Source Tree TLVs defined in [RFC6826], except that instead of the
instead of the Source field they have the RP field, and this field Source field they have the RP field, and this field carries the
carries the address of the RP, as follows: address of the 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 7, line 29 skipping to change at page 7, line 43
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ | Group ~ ~ | Group ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ | ~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: TBD (to be assigned by IANA). Type: TBD (to be assigned by IANA).
Length: 32 Length: 32
Source: 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 for in-band signaling for IP
multicast source trees specified in [MLDP-IN-BAND-SIGNALLING], except multicast source trees specified in [RFC6826], except that while the
that while the latter signals (S,G) state using Transit IPv4/IPv6 latter signals (S,G) state using Transit IPv4/IPv6 Source TLVs, the
Source TLVs, the former signals (*,G) state using Transit IPv4/IPv6 former signals (*,G) state using Transit IPv4/IPv6 Shared Tree TLVs.
Shared Tree TLVs.
4.2. Originating Source Active auto-discovery routes 4.2. Originating Source Active auto-discovery routes (Option 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 LSR creates an (S, G) state as a result of receiving an 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), if mLDP Label Map with the Transit IPv4/IPv6 Source TLV for (S, G), if
all of the following are true: all of 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,
skipping to change at page 10, line 20 skipping to change at page 10, line 26
6. Security Considerations 6. Security Considerations
All the security considerations for mLDP ([mLDP]) apply here. All the security considerations for mLDP ([mLDP]) apply here.
7. Acknowledgements 7. Acknowledgements
Use of Source Active auto-discovery routes was borrowed from [MVPN- Use of Source Active auto-discovery routes was borrowed from [MVPN-
BGP]. Some text in this document was borrowed from [MVPN-BGP]. BGP]. Some text in this document was borrowed from [MVPN-BGP].
Some of the text in this document was borrowed from [MLDP-IN-BAND- Some of the text in this document was borrowed from [RFC6826].
SIGNALLING].
We would like to acknowledge Arkadiy Gulko for his review and We would like to acknowledge Arkadiy Gulko for his review and
comments. comments.
We would also like to thank Xuxiaohu, Gregory Mirsky, and Rajiv Asati
for their review and comments.
8. Normative References 8. Normative References
[mLDP] Minei, I., "Label Distribution Protocol Extensions for Point- [mLDP] Minei, I., "Label Distribution Protocol Extensions for Point-
to- Multipoint and Multipoint-to-Multipoint Label Switched Paths", to- Multipoint and Multipoint-to-Multipoint Label Switched Paths",
RFC6388, November 2011. RFC6388, November 2011.
[MLDP-IN-BAND-SIGNALLING] "In-band signaling for Point-to-Multipoint [RFC6826] "In-band signaling for Point-to-Multipoint and Multipoint-
and Multipoint-to-Multipoint Label Switched Paths", I. Wijnands et to-Multipoint Label Switched Paths", I. Wijnands et al., RFC6826,
al., RFC6826, January 2013 January 2013
[MVPN-BGP] "BGP Encodings and Procedures for Multicast in MPLS/BGP IP [MVPN-BGP] "BGP Encodings and Procedures for Multicast in MPLS/BGP IP
VPNs", R. Aggarwal et al., RFC6514, February 2012 VPNs", R. Aggarwal et al., RFC6514, February 2012
[RFC1997] R. Chandra, P. Traina, T. Li, "BGP Communities Attribute", [RFC1997] R. Chandra, P. Traina, T. Li, "BGP Communities Attribute",
RFC1997, August 1996. RFC1997, August 1996.
[RFC2119] "Key words for use in RFCs to Indicate Requirement [RFC2119] "Key words for use in RFCs to Indicate Requirement
Levels.", Bradner, RFC2119, March 1997. Levels.", Bradner, RFC2119, March 1997.
9. Non-normative References 9. Informative References
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol
Specification (Revised)", RFC 4601, August 2006. Specification (Revised)", RFC 4601, August 2006.
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for
IP", RFC 4607, August 2006. IP", RFC 4607, August 2006.
10. Authors' Addresses 10. Authors' Addresses
 End of changes. 27 change blocks. 
49 lines changed or deleted 57 lines changed or added

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