MPLS Working Group IJ. Wijnands, Ed. Internet-Draft Cisco Intended status: Standards Track A. Gulko Expires: January 9, 2014 Thomson Reuters U. Joorde Deutsche Telekom J. Tantsura Ericsson July 8, 2013 mLDP in-band signalling Wildcard encoding draft-wijnands-mpls-mldp-in-band-wildcard-encoding-00 Abstract Documents [RFC6826] and [I-D.ietf-l3vpn-mldp-vrf-in-band-signaling] define a solution to splice an IP multicast tree together with a multipoint LSP in the global or VRF context. In these drafts the Multipoint Label Distribution Protocol (mLDP) Opaque TLV encodings have been documented for Source specific and Bidir IP multicast trees. For each IP multicast tree a multipoint LSP is created. There are scenarios where it is beneficial to support shared trees and allow aggregation such that fewer multipoint LSPs are created in the network. This document defines wildcard encodings to be used for the Source or Group fields of the existing opaque encodings. With the wildcard encoding it is possible to create a single multipoint LSP that is used to represent *all* sources for a given multicast group or *all* groups for a given source. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 9, 2014. Copyright Notice Wijnands, et al. Expires January 9, 2014 [Page 1] Internet-Draft mLDP in-band signalling wildcard encoding July 2013 Copyright (c) 2013 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. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Wijnands, et al. Expires January 9, 2014 [Page 2] Internet-Draft mLDP in-band signalling wildcard encoding July 2013 Table of Contents 1. Terminology and Definitions . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. PIM shared tree forwarding . . . . . . . . . . . . . . . . . . 5 4. IGMP/MLD proxying . . . . . . . . . . . . . . . . . . . . . . 6 5. Selective Source mapping . . . . . . . . . . . . . . . . . . . 6 6. Wildcard Source . . . . . . . . . . . . . . . . . . . . . . . 6 7. Wildcard Group . . . . . . . . . . . . . . . . . . . . . . . . 7 8. Root node address discovery . . . . . . . . . . . . . . . . . 8 9. Anycast RP . . . . . . . . . . . . . . . . . . . . . . . . . . 8 10. Wildcard encoding . . . . . . . . . . . . . . . . . . . . . . 8 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 13. Security Considerations . . . . . . . . . . . . . . . . . . . 9 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 14.1. Normative References . . . . . . . . . . . . . . . . . . 9 14.2. Informative References . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Wijnands, et al. Expires January 9, 2014 [Page 3] Internet-Draft mLDP in-band signalling wildcard encoding July 2013 1. Terminology and Definitions PIM: Protocol Independent Multicast. IGMP: Internet Group Management Protocol. MLD: Multicast Listener Discovery. IP multicast tree: An IP multicast distribution tree identified by a IP multicast group address and optionally a Source IP address, also referred to as (S,G) and (*,G). MP-LSP: A P2MP or MP2MP LSP. PIM-ASM: PIM Any Source Multicast. PIM-SSM: PIM Source Specific Multicast. PIM-SM: PIM Sparse-mode Multicast. RP: The PIM Rendezvous Point. mLDP: Multipoint LDP. In-band signaling: Using the opaque value of a mLDP FEC element to carry the (S,G) or (*,G) identifying a particular IP multicast tree. Ingress LSR: Source of the P2MP LSP, also referred to as root node. Egress LSR: A LSR that has receivers attached, also referred to as leaf node. Threshold Infinity: A PIM-SM procedure where no source specific multicast (S,G) trees are created for multicast packets that are forwarded down the shared tree (*,G). 2. Introduction Documents [RFC6826] and [I-D.ietf-l3vpn-mldp-vrf-in-band-signaling] define a solution to splice an IP multicast tree together with a multipoint LSP in the global or VRF context. In these drafts the Multipoint Label Distribution Protocol (mLDP) Opaque TLV encodings have been documented for Source specific and Bidir IP multicast trees. For each IP multicast tree a mLDP MP-LSP is created. There are scenarios where it is beneficial to support shared trees and allow aggregation such that fewer multipoint LSPs are created in the Wijnands, et al. Expires January 9, 2014 [Page 4] Internet-Draft mLDP in-band signalling wildcard encoding July 2013 network. This document defines wildcard encodings that can be used in Source or Group fields of the existing Opaque TLV encodings. With the wildcard encoding it is possible to create a single multipoint LSP used to represent *all* sources for a given multicast group or *all* groups for a given source. The behaviour of an mLDP in-band signalled multipoint LSPs containing a wildcard entry follows the procedures defined in [RFC6826] and [I-D.ietf-l3vpn-mldp-vrf-in-band-signaling]. This draft does not talk about already defined procedures but only documents the differences. There are a few scenarios (not limited to) where wildcard encoding is useful, for example; o PIM Shared tree forwarding with threshold infinity. o IGMP/MLD proxying. o Selective Source mapping. These scenarios are discussed in this draft below. 3. PIM shared tree forwarding PIM [RFC4601] has the concept of a shared tree, known as (*,G). This means, *all* Sources for a given Group in the ASM range. The (*,G) is built towards the Rendezvous Point (RP) that typically joins *all* multicast sources for this group. The RP will then forward all the IP multicast packets for this group down the (*,G) tree towards the receivers. There are several procedures how the RP learns about these sources, for example; PIM Registers [RFC4601], MSDP [RFC3618] or a Source that is directly connected to the RP. In some cases, the last hop routers does not wish to join the source trees, and expect to receive all the traffic for group G from the (*,G) tree; in this case, we say that the last hop routers have 'threshold infinity' for group G. This is optional behaviour documented in the [RFC4601]. This is often used in deployments where the RP is between the multicast sources and the multicast receivers for group G, i.e., the shortest path from any source to any receiver of the group goes through the RP. In this scenario, there is no advantage for a last hop router to join a source tree for the group, since joining a source tree would not change the path of the multicast data from the source. The only effect of executing the complicated procedures for joining a source tree and pruning the source off the shared tree would be to an increase of the amount of multicast routing state. Wijnands, et al. Expires January 9, 2014 [Page 5] Internet-Draft mLDP in-band signalling wildcard encoding July 2013 This deployment model can be implemented using wildcards. The egress router will splice the (*,G) IP multicast tree to a mLDP Multipoint LSP where the Source address is encoded as wildcard entry. In scenarios where it does not make sense to apply "threshold infinity" to a given ASM group, a more complex set of procedures are needed, as per [I-D.rekhter-pim-sm-over-mldp]. 4. IGMP/MLD proxying There are scenarios where the multicast senders and receivers are directly connected to a MPLS routing domain and mLDP is available. In these cases we can apply "IGMP/MLD proxying" and avoid using PIM as a multicast routing protocol to transport multicast packets from the senders to the receivers. The senders and receivers consider the MPLS domain to be single hop between each other. [RFC4605] documents procedures where a multicast routing protocol is not nessesary to build a 'simple tree'. Within the MPLS domain mLDP will be used to build a 'spanning tree' to avoid looping and duplication of packets, but for the point of view of the senders and receivers this is hidden. The procedures as defined [RFC4605] are applicable since the senders and receivers are considered to be one hop away from each other. For mLDP to build a tree, it needs to know the root of the tree. Following the procedures as defined in [RFC4605] we depend on manual configuration of the mLDP root for the ASM multicast group. The Source will be encoded as a wildcard entry. 5. Selective Source mapping In IPTV deployments, rather often, the content servers are co-located in a few sites. Popular channels are often statically configured and always forwarded over the core MPLS network to the egress routers. Since these channels are statically defined, they MAY also be forwarded over a multipoint LSP with wildcard encoding. The sort of wildcard encoding that needs to be used (Source and/or Group) depends on the Source/Group allocation policy of the IPTV provider. Other options are to use MSDP [RFC3618] or BGP AD [RFC6513] for source discovery by the ingress LSR. Based on the received wildcard, the ingress LSR can make a selection out of the IP multicast streams it has state for. 6. Wildcard Source When the IP multicast component on the ingress LSR has received a Wijnands, et al. Expires January 9, 2014 [Page 6] Internet-Draft mLDP in-band signalling wildcard encoding July 2013 wildcard source from mLDP it may have been initiated by one of the scenarios described in this draft. How the wildcard source is to be interpretted is a local matter and follows the rules below; 1. If PIM is enabled and the group is a non-bidirectional ASM group, the wildcard source is treated as having received a (*,G) IGMP/ MLD report from a downstream node and the procedures as defined in [RFC4601] are followed. 2. If PIM is enabled and the group mode is PIM-SSM, all multicast sources known for the group on the root node must be forwarded down the multipoint LSP. 3. If PIM is not enabled for this group, the wildcard source is treated as having received a (*,G) IGMP/MLD report from a downstream node and the procedures as defined in [RFC4605] are followed. The IP multicast component on the egress LSR determins when a Wildcard Source is to be used in a mLDP Opaque TLV encoding. How the IP multicast component determins this is a local matter and potentially subjected to explicit user configuration. It MAY however use the following rules (with or without explicit user configuration); 1. If PIM is enabled, the group is a non-bidirectional ASM group and the RP is reachable via a BGP route, a Wildcard Source encoding MAY be used to signal group membership (*,G) to the ingress LSR, using the BGP next hop as the ingress LSR (root of the LSP). Also see Section 8. 2. If PIM is not enabled for this group and an IGMP/MLD group membership report has been received, the IP multicast component may use a Wildcard Source encoding to signal the group membership (*,G) to a Proxy device (root of the LSP). The procedures how to determin the Proxy device for a given group are defined in [RFC4605]. The wildcard source encoding MUST NOT appear in the "Bidir TLVs" that are defined in [RFC6826] sections 3.3 and 3.4." A wildcard group in combination with a wildcard source encoding is under investigation. 7. Wildcard Group When the IP multicast component on the root node receives a wildcard Wijnands, et al. Expires January 9, 2014 [Page 7] Internet-Draft mLDP in-band signalling wildcard encoding July 2013 group encoding, the root node SHOULD apply the wildcard encoding to the existing IP multicast routing table and forward all the IP multicast stream(s) that match the given Source. Note, this behaviour is independent of the PIM group mode (ie. ASM or SSM). The IP multicast component on the egress LSR determins when a Wildcard Group is to be used in a mLDP Opaque TLV encoding. How the IP multicast component determins this is a local matter and subjected to explicit user configuration. The wildcard group encoding for PIM bidir is under investigation. A wildcard source in combination with a wildcard group encoding is under investigation. 8. Root node address discovery Documents [RFC6826] and [I-D.ietf-l3vpn-mldp-vrf-in-band-signaling] describe procedures to discover the mLDP root node address by using the Source of the IP multicast stream. When a wildcard source encoding is used, PIM is enabled and the group is a non-bidirectional ASM group, a similar procedure s applied. The only different with the above mentioned procedures is that the Proxy device or RP address is used instead of the Source to discover the mLDP root node address. In all other cases some sort of manual configuration is applied in order to find the root node. Note, finding the root node is a local implementation matter and not limited to the solutions mentioned in this draft. 9. Anycast RP With in-band signalling there is likely no RP to Group mappings distribution taking place over the MPLS core to the different IP multicast sites. The RP address is likely statically configured on each multicast site. In these cases it makes sense to configure an Anycast RP Address to provide redundancy. See [RFC3446] for more details. 10. Wildcard encoding The source and group fields in the Transit IPv4, IPv6, VPNv4 and VPNv6 Source TLVs, as documented in [RFC6826] and [I-D.ietf-l3vpn-mldp-vrf-in-band-signaling] only allow valid IP addresses to be encoded. This document proposes to use a source/ Wijnands, et al. Expires January 9, 2014 [Page 8] Internet-Draft mLDP in-band signalling wildcard encoding July 2013 group field of *all* zero's to be used as wildcard encoding. 11. Acknowledgements The authors would like to thank Eric Rosen for his valuable comments. 12. IANA Considerations There are no new allocations required from IANA. 13. Security Considerations There are no security considerations other then ones already mentioned in [RFC6826] and [I-D.ietf-l3vpn-mldp-vrf-in-band-signaling]. 14. References 14.1. Normative References [I-D.ietf-l3vpn-mldp-vrf-in-band-signaling] Wijnands, I., Hitchen, P., Leymann, N., Henderickx, W., and a. arkadiy.gulko@thomsonreuters.com, "Multipoint Label Distribution Protocol In-Band Signaling in a VRF Context", draft-ietf-l3vpn-mldp-vrf-in-band-signaling-01 (work in progress), June 2013. [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, "Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")", RFC 4605, August 2006. [RFC6826] Wijnands, IJ., Eckert, T., Leymann, N., and M. Napierala, "Multipoint LDP In-Band Signaling for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", RFC 6826, January 2013. 14.2. Informative References [I-D.rekhter-pim-sm-over-mldp] Rekhter, Y. and R. Aggarwal, "Carrying PIM-SM in ASM mode Trees over P2MP mLDP LSPs", draft-rekhter-pim-sm-over-mldp-04 (work in progress), August 2011. Wijnands, et al. Expires January 9, 2014 [Page 9] Internet-Draft mLDP in-band signalling wildcard encoding July 2013 [RFC3446] Kim, D., Meyer, D., Kilmer, H., and D. Farinacci, "Anycast Rendevous Point (RP) mechanism using Protocol Independent Multicast (PIM) and Multicast Source Discovery Protocol (MSDP)", RFC 3446, January 2003. [RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery Protocol (MSDP)", RFC 3618, October 2003. [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006. [RFC6513] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP VPNs", RFC 6513, February 2012. Authors' Addresses IJsbrand Wijnands (editor) Cisco De kleetlaan 6a Diegem, 1831 Belgium Phone: Email: ice@cisco.com Arkadiy Gulko Thomson Reuters 195 Broadway New York NY 10007 USA Email: arkadiy.gulko@thomsonreuters.com Uwe Joorde Deutsche Telekom Hammer Str. 216-226 Muenster D-48153 DE Email: Uwe.Joorde@telekom.de Wijnands, et al. Expires January 9, 2014 [Page 10] Internet-Draft mLDP in-band signalling wildcard encoding July 2013 Jeff Tantsura Ericsson 300 Holger Way San Jose, California 95134 USA Email: Jeff.Tantsura@ericsson.com Wijnands, et al. Expires January 9, 2014 [Page 11]