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]