Routing Area Working Group A. Atlas, Ed.
Internet-Draft R. Kebler
Intended status: Standards Track Juniper Networks
Expires: January 13, 2014 IJ. Wijnands
Cisco Systems, Inc.
A. Csaszar
G. Enyedi
Ericsson
July 12, 2013
An Architecture for Multicast Protection Using Maximally Redundant Trees
draft-atlas-rtgwg-mrt-mc-arch-02
Abstract
Failure protection is desirable for multicast traffic, whether
signaled via PIM or mLDP. Different mechanisms are suitable for
different use-cases and deployment scenarios. This document
describes the architecture for global protection (aka multicast live-
live) and for local protection (aka fast-reroute).
The general methods for global protection and local protection using
alternate-trees are dependent upon the use of Maximally Redundant
Trees. Local protection can also tunnel traffic in unicast tunnels
to take advantage of the routing and fast-reroute mechanisms
available for IP/LDP unicast destinations.
The failures protected against are single link or node failures.
While the basic architecture might support protection against shared
risk group failures, algorithms to dynamically compute MRTs
supporting this are for future study.
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."
Atlas, et al. Expires January 13, 2014 [Page 1]
Internet-Draft MRT FRR Architecture July 2013
This Internet-Draft will expire on January 13, 2014.
Copyright Notice
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.
Atlas, et al. Expires January 13, 2014 [Page 2]
Internet-Draft MRT FRR Architecture July 2013
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Maximally Redundant Trees (MRTs) . . . . . . . . . . . . . 4
1.2. MRTs and Multicast . . . . . . . . . . . . . . . . . . . . 6
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Use-Cases and Applicability . . . . . . . . . . . . . . . . . 8
4. Global Protection: Multicast Live-Live . . . . . . . . . . . . 9
4.1. Creation of MRMTs . . . . . . . . . . . . . . . . . . . . 10
4.2. Traffic Self-Identification . . . . . . . . . . . . . . . 11
4.2.1. Merging MRMTs for PIM if Traffic Doesn't
Self-Identify . . . . . . . . . . . . . . . . . . . . 12
4.3. Convergence Behavior . . . . . . . . . . . . . . . . . . . 13
4.4. Inter-area/level Behavior . . . . . . . . . . . . . . . . 14
4.4.1. Inter-area Node Protection with 2 border routers . . . 15
4.4.2. Inter-area Node Protection with > 2 Border Routers . . 16
4.5. PIM . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.5.1. Traffic Handling: RPF Checks . . . . . . . . . . . . . 17
4.6. mLDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5. Local Repair: Fast-Reroute . . . . . . . . . . . . . . . . . . 17
5.1. PLR-driven Unicast Tunnels . . . . . . . . . . . . . . . . 18
5.1.1. Learning the MPs . . . . . . . . . . . . . . . . . . . 19
5.1.2. Using Unicast Tunnels and Indirection . . . . . . . . 19
5.1.3. MP Alternate Traffic Handling . . . . . . . . . . . . 20
5.1.4. Merge Point Reconvergence . . . . . . . . . . . . . . 21
5.1.5. PLR termination of alternate traffic . . . . . . . . . 21
5.2. MP-driven Unicast Tunnels . . . . . . . . . . . . . . . . 21
5.3. MP-driven Alternate Trees . . . . . . . . . . . . . . . . 22
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
8. Security Considerations . . . . . . . . . . . . . . . . . . . 23
9. Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . . 23
9.1. MP-driven Alternate Trees . . . . . . . . . . . . . . . . 23
9.1.1. PIM details for Alternate-Trees . . . . . . . . . . . 26
9.1.2. mLDP details for Alternate-Trees . . . . . . . . . . . 26
9.1.3. Traffic Handling by PLR . . . . . . . . . . . . . . . 26
9.2. Methods Compared for PIM . . . . . . . . . . . . . . . . . 27
9.3. Methods Compared for mLDP . . . . . . . . . . . . . . . . 27
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
10.1. Normative References . . . . . . . . . . . . . . . . . . . 27
10.2. Informative References . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
Atlas, et al. Expires January 13, 2014 [Page 3]
Internet-Draft MRT FRR Architecture July 2013
1. Introduction
This document describes how the algorithms in
[I-D.enyedi-rtgwg-mrt-frr-algorithm], which are used in
[I-D.ietf-rtgwg-mrt-frr-architecture] for unicast IP/LDP fast-
reroute, can be used to provide protection for multicast traffic. It
specifically applies to multicast state signaled by PIM[RFC4601] or
mLDP[RFC6388]. There are additional protocols that depend upon these
(e.g. VPLS, mVPN, etc.) and consideration of the applicability to
such traffic will be in a future version.
In this document, global protection is used to refer to the method of
having two maximally disjoint multicast trees where traffic may be
sent on both and resolved by the receiver. This is similar to the
ability with RSVP-TE LSPs to have a primary and a hot standby, except
that it can operate in 1+1 mode. This capability is also referred to
as multicast live-live and is a generalized form of that discussed in
[I-D.ietf-rtgwg-mofrr]. In this document, local protection refers to
the method of having alternate ways of reaching the pre-identified
merge points upon detection of a local failure. This capability is
also referred to as fast-reroute.
This document describes the general architecture, framework, and
trade-offs of the different approaches to solving these general
problems. It will recommend how to generally provide global
protection and local protection for mLDP and PIM traffic. Where
protocol extensions are necessary, they will be defined in separate
documents as follows.
o Global 1+1 Protection Using PIM
o Global 1+1 Protection Using mLDP
o Local Protection Using mLDP:
[I-D.wijnands-mpls-mldp-node-protection]This document describes
how to provide node-protection and the necessary extensions using
targeted LDP session.
o Local Protection Using PIM
1.1. Maximally Redundant Trees (MRTs)
Maximally Redundant Trees (MRTs) are described in
[I-D.enyedi-rtgwg-mrt-frr-algorithm]; here we only give a brief
description about the concept. A pair of MRTs is a pair of directed
spanning trees (red and blue tree) with a common root, directed so
that each node can be reached from the root on both trees. Moreover,
these trees are redundant, since they are constructed so that no
Atlas, et al. Expires January 13, 2014 [Page 4]
Internet-Draft MRT FRR Architecture July 2013
single link or single node failure can separate any node from the
root on both trees, unless that failed link or node is splitting the
network into completely separated components (e.g. the link or node
was a cut-edge or cut-vertex).
Although for multicast, the arcs (directed links) are directed away
from the root instead of towards the root, the same MRT computations
are used and apply. This is similar to how multicast uses unicast
routing's next-hops as the upstream-hops. Thus this definition
slightly differs from the one presented in
[I-D.enyedi-rtgwg-mrt-frr-algorithm], since the arcs are directed
away and not towards the root. When we need two paths towards a
given destination and not two away from it (e.g. for unicast detours
for local repair solutions), we only need to reverse the arcs from
how they are used for the unicast routing case; thus constructing
MRTs towards or away from the root is the same problem. A pair of
MRTs is depicted in Figure 1.
[E]---[D]---| |---[J]
| | | | |
| | | | |
[R] [F] [C]---[G] |
| | | | |
| | | | |
[A]---[B]---| |---[H]
(a) a network
[E]<--[D]---| |-->[J] [E]<--[D] [J]
^ | | | | ^ ^
| V V | | | |
[R] [F] [C]-->[G] | [R] [F] [C]-->[G] |
| | | ^ ^ | |
V V V | | | |
[A]<--[B] [H] [A]-->[B]---| |-->[H]
(b) Blue MRT of root R (c) Red MRT of root R
Figure 1: A network and two MRTs found in it
It is important to realize that this redundancy criterion does not
imply that, after a failure, either of the MRTs remains intact, since
a node failure must affect any spanning tree. Redundancy here means
that there will be a set of nodes, which can be reached along the
blue MRT, and there will be another set, which remains reachable
along the red MRT. As an example, suppose that node F goes down;
that would separate B and A on the blue MRT and D and E on the red
Atlas, et al. Expires January 13, 2014 [Page 5]
Internet-Draft MRT FRR Architecture July 2013
MRT. Naturally, it is possible that the intersection of these two
sets is not empty, e.g. C, G, H and J will remain reachable on both
MRTs. Additionally, observe that a single link can be used in both
of the trees in different directions, so even a link failure can cut
both trees. In this example, the failure of link F<->B leads to the
same reachability sets.
Finally, it is critical to recall that a pair of MRTs is always
constructed together and they are not SPTs. While it would be useful
to have an algorithm that could find a redundant pair for a given
tree (e.g. for the SPT), that is impossible in general. Moreover, if
there is a failure and at least one of the trees change, the other
tree may need to change as well. Therefore, even if a node still
receives the traffic along the red tree, it cannot keep the old red
tree, and construct a blue pair for it; there can be reconfiguration
in cases when traditional shortest-path-based-thinking would not
expect it. To converge to a new pair of disjoint MRTs, it is
generally necessary to update both the blue MRT and the red MRT.
The two MRTs provide two separate forwarding topologies that can be
used in addition to the default shortest-path-tree (SPT) forwarding
topology (usually MT-ID 0). There is a Blue MRT forwarding topology
represented by one MT-ID; similarly there is a Red MRT forwarding
topology represented by a different MT-ID. Naturally, a multicast
protocol is required to use the forwarding topologies information to
build the desired multicast trees. The multicast protocol can simply
request appropriate upstream interfaces, but include the MT-ID when
needed.
1.2. MRTs and Multicast
Maximally Redundant Trees (MRT) provide two advantages for protecting
multicast traffic. First, for global protection, MRTs are precisely
what needs to be computed to have maximally redundant multicast
distribution trees. Second, for local repair, MRTs ensure that there
will protection to the merge points; the certainty of a path from any
merge point to the PLR that avoids the failure node allows for the
creation of alternate trees.
A known disadvantage of MRT, and redundant trees in general, is that
the trees do not necessarily provide shortest detour paths. Modeling
is underway to investigate and compare the MRT lengths for the
different algorithm options [I-D.enyedi-rtgwg-mrt-frr-algorithm].
2. Terminology
Atlas, et al. Expires January 13, 2014 [Page 6]
Internet-Draft MRT FRR Architecture July 2013
2-connected: A graph that has no cut-vertices. This is a graph
that requires two nodes to be removed before the network is
partitioned.
2-connected cluster: A maximal set of nodes that are 2-connected.
2-edge-connected: A network graph where at least two links must be
removed to partition the network.
ADAG: Almost Directed Acyclic Graph - a graph that, if all links
incoming to the root were removed, would be a DAG.
block: Either a 2-connected cluster, a cut-edge, or an isolated
vertex.
cut-link: A link whose removal partitions the network. A cut-link
by definition must be connected between two cut-vertices. If
there are multiple parallel links, then they are referred to as
cut-links in this document if removing the set of parallel links
would partition the network.
cut-vertex: A vertex whose removal partitions the network.
DAG: Directed Acyclic Graph - a graph where all links are directed
and there are no cycles in it.
GADAG: Generalized ADAG - a graph that is the combination of the
ADAGs of all blocks.
Maximally Redundant Trees (MRT): A pair of trees where the path
from any node X to the root R along the first tree and the path
from the same node X to the root along the second tree share the
minimum number of nodes and the minimum number of links. Each
such shared node is a cut-vertex. Any shared links are cut-links.
Any RT is an MRT but many MRTs are not RTs.
Maximally Redundant Multicast Trees (MRMT): A pair of multicast
trees built of the sub-set of MRTs that is needed to reach all
interested receivers.
network graph: A graph that reflects the network topology where all
links connect exactly two nodes and broadcast links have been
transformed into the standard pseudo-node representation.
Redundant Trees (RT): A pair of trees where the path from any node
X to the root R along the first tree is node-disjoint with the
path from the same node X to the root along the second tree.
These can be computed in 2-connected graphs.
Atlas, et al. Expires January 13, 2014 [Page 7]
Internet-Draft MRT FRR Architecture July 2013
Merge Point (MP): For local repair, a router at which the alternate
traffic rejoins the primary multicast tree. For global
protection, a router which receives traffic on multiple trees and
must decide which stream to forward on.
Point of Local Repair (PLR): The router that detects a local
failure and decides whether and when to forward traffic on
appropriate alternates.
MT-ID: Multi-topology identifier. The default shortest-path-tree
topology is MT-ID 0.
MultiCast Ingress (MCI): Multicast Ingress, the node where the
multicast stream enters the current transport technology (MPLS-
mLDP or IP-PIM) domain. This maybe the router attached to the
multicast source, the PIM Rendezvous Point (RP) or the mLDP Root
node address.
Upstream Multicast Hop (UMH): Upstream Multicast Hop, a candidate
next-hop that can be used to reach the MCI of the tree.
Stream Selection: The process by which a router determines which of
the multiple primary multicast streams to accept and forward. The
router can decide on a packet-by-packet basis or simply per-
stream. This is done for global protection 1+1 and described in
[I-D.ietf-rtgwg-mofrr].
MultiCast Egress (MCE): Multicast Egress, a node where the
multicast stream exists the current transport technology (MPLS-
mLDP or IP-PIM) domain. This is usually a receiving router that
may forward the multicast traffic on towards receivers based upon
IGMP or other technology.
3. Use-Cases and Applicability
Protection of multicast streams has gained importance with the use of
multicast to distribute video, including live video such as IP-TV.
There are a number of different scenarios and uses of multicast that
require protection. A few preliminary examples are described below.
o When video is distributed via IP or MPLS for a cable application,
it is desirable to have global protection 1+1 so that the
customer-perceived impact is limited. A QAM can join two
multicast groups and determine which stream to use based upon the
stream quality. A network implementing this may be custom-
engineered for this particular purpose.
Atlas, et al. Expires January 13, 2014 [Page 8]
Internet-Draft MRT FRR Architecture July 2013
o In financial markets, stock ticker data is distributed via
multicast. The loss of data can have a significant financial
impact. Depending on the network, either global protection 1+1 or
local protection can minimize the impact.
o Several solutions exist for updating software or firmwares of a
large number of end-user or operator-owned networking equipment
that are based on IP multicast. Since IP multicast is based on
datagram transport so taking care of lost data is cumbersome and
decreases the advantages offered by multicast. Solutions may rely
on sending the updates several times: a properly protected network
may result in that less repetitions are required. Other solutions
rely on the recipent asking for lost data segments explicitly on-
demand. A network failure could cause data loss for a significant
number of receivers, which in turn would start requesting the the
lost data in a burst that could overload the server. Properly
engineered multicast fast reroute would minimise such impacts.
o Some providers offer multicast VPN services to their customers.
SLAs between the customer and provider may set low packet loss
requirements. In such cases interruptions longer than the outage
timescales targeted by FRR could cause direct financial losses for
the provider.
Global protection 1+1 uses maximally redundant multicast trees
(MRMTs) to simultaneously distribute a multicast stream on both
MRMTs. The disadvantage is the extra state and bandwidth
requirements of always sending the traffic twice. The advantage is
that the latency of each MRMT can be known and the receiver can
select the best stream.
Local protection provides a patch around the fault while the
multicast tree reconverges. When PLR replication is used, there is
no extra multicast state in the network, but the bandwidth
requirements vary based upon how many potential merge-points must be
provided. When alternate-trees are used, there is extra multicast
state but the bandwidth requirements on a link can be minimized to no
more than once for the primary multicast tree traffic and once for
the alternate-tree traffic.
4. Global Protection: Multicast Live-Live
In MoFRR [I-D.ietf-rtgwg-mofrr], the idea of joining both a primary
and a secondary tree is introduced with the requirement that the
primary and secondary trees be link and node disjoint. This works
well for networks where there are dual-planes, as explained in
[I-D.ietf-rtgwg-mofrr]. For other networks, it is still desirable to
Atlas, et al. Expires January 13, 2014 [Page 9]
Internet-Draft MRT FRR Architecture July 2013
have two disjoint multicast trees and allow a receiver to join both
and make its own decision about which traffic to accept.
Using MRTs gives the ability to guarantee that the two trees are as
disjoint as possible and dynamically recomputed whenever the topology
changes. The MRTs used are rooted at the MultiCast Ingress (MCI).
One multicast tree is created using the Blue MRT forwarding topology.
The second multicast tree is created using the Red MRT forwarding
topology. This can be accomplished by specifying the appropriate
MT-ID associated with each forwarding topology.
There are four different aspects of using MRTs for 1+1 Global
Protection that are necessary to consider. They are as follows.
1. Creation of the maximally redundant multicast trees (MRMTs) based
upon the forwarding topologies.
2. Traffic Identification: How to handle traffic when the two MRMTs
overlap due to a cut-vertex or cut-link.
3. Convergence: How to converge after a network change and get back
to a protected state.
4. Inter-area/inter-level Behavior: How to compute and use MRMTs
when the multicast source is outside the area/level and how to
provide border-router protection.
4.1. Creation of MRMTs
The creation of the two maximally redundant multicast trees occurs as
described below. This assumes that the next-hops to the MCI
associated with the Blue and Red forwarding topologies have already
been computed and stored.
1. A receiving router determines that it wants to join both the Blue
tree and the Red tree. The details on how it does this decision
are not covered in this document and could be based on
configuration, additional protocols, etc.
2. The router selects among the Blue next-hops an Upstream Multicast
Hop (UMH) to reach the MCI node. The router joins the tree
towards the selected UMH including a multi-topology id (MT-ID)
identifying the Blue MRT.
3. The router selects among the Red next-hops an Upstream Multicast
Hop (UMH) to reach the MCI node. The router joins the tree
towards the selected UMH including a multi-topology id (MT-ID)
identifying the Red MRT.
Atlas, et al. Expires January 13, 2014 [Page 10]
Internet-Draft MRT FRR Architecture July 2013
4. When a router receives a tree setup request specifying a
particular MT-ID (e.g. Color), then the router selects among the
Color next-hops to the MCI a UMH node, creates the necessary
multicast state, and joins the tree towards the UMH node.
4.2. Traffic Self-Identification
Two maximally redundant trees will share any cut-vertices and cut-
links in the network. In the multicast global protection 1+1 case,
this means that the potential single failures of the other nodes and
links in the network are still protected against. If each cut-vertex
cannot associate traffic to a particular MRMT, then the traffic would
be incorrectly replicated to both MRMT resulting in complete
duplication of traffic. An example of such MRTs is given earlier in
Figure 1 and repeated below in Figure 2, where there are two cut-
vertices C and G and a cut-link C<->G.
[E]---[D]---| |---[J]
| | | | |
| | | | |
[R] [F] [C]---[G] |
| | | | |
| | | | |
[A]---[B]---| |---[H]
(a) a network
[E]<--[D]---| |-->[J] [E]<--[D] [J]
^ | | | | ^ ^
| V V | | | |
[R] [F] [C]-->[G] | [R] [F] [C]-->[G] |
| | | ^ ^ | |
V V V | | | |
[A]<--[B] [H] [A]-->[B]---| |-->[H]
(b) Blue MRT of root R (c) Red MRT of root R
Figure 2: A network and two MRTs found in it
In this example, traffic from the multicast source R to a receiver G,
J, or H will cross link C<->G on both the Blue and Red MRMTs. When
this occurs, there are several different possibilities depending upon
protocol.
Atlas, et al. Expires January 13, 2014 [Page 11]
Internet-Draft MRT FRR Architecture July 2013
mLDP: Different label bindings will be created for the Blue and Red
MRMTs. As specified in [I-D.iwijnand-mpls-mldp-multi-topology],
the P2MP FEC Element will use the MT IP Address Family to encode
the Root node address and MRT T-ID. Each MRMT will therefore have
a different P2MP FEC Element and be assigned an independent label.
PIM: There are three different ways to handle IP traffic forwarded
based upon PIM when that traffic will overlap on a link.
A. Different Groups: If different multicast groups are used for
each MRMT, then the traffic clearly indicates which MRMT it
belongs to. In this case, traffic on the Blue MRMT would use
multicast group G-blue and traffic on the Red MRMT would use
multicast group G-red.
B. Different Source Loopbacks: Another option is to use different
IP addresses for the source S, so S might announce S-red and
S-blue. In this case, traffic on the Blue MRMT would have an
IP source of S-blue and traffic on the Red MRMT would have an
IP source of S-red.
C. Stream Selection and Merging: The third option, described in
Section 4.2.1, is to have a router that gets (S,G) Joins for
both the Blue MT-ID and the Red MT-ID merge those into a
single tree. The router may need to select which upstream
stream to use, just as if it were a receiving router.
There are three options presented for PIM. The most appropriate will
depend upon deployment scenario as well as router capabilities.
4.2.1. Merging MRMTs for PIM if Traffic Doesn't Self-Identify
When traffic doesn't self-identify, the cut-vertices must follow
specific rules to avoid traffic duplication. This section describes
that behavior which allows the same (S,G) to be used for both the
Blue MT-ID and Red MT-ID (e.g. when the traffic doesn't self-identify
as to its MT-ID).
The behavior described in this section differs from the conflict
resolution described in [RFC6420] because these rules apply to the
Global Protection 1+1 case. Specifically, it is not sufficient for a
upstream router to pick only one of the two MT-IDs to join because
that does not maximize the protection provided.
As described in [RFC6420], a router that receives (S,G) Joins for
both the Blue MT-ID and the Red MT-ID can merge the set of downstream
interfaces in its forwarding entry. Unlike the procedures defined in
[RFC6420], the router must send a Join upstream for each MT-ID. If a
Atlas, et al. Expires January 13, 2014 [Page 12]
Internet-Draft MRT FRR Architecture July 2013
router has different upstream interfaces for these MRMTs, then the
router will need to do stream selection and forward the selected
stream to its outgoing interfaces, just as if it were an MCE. The
stream selection methods of detecting failures and handle traffic
discarding are described in [I-D.ietf-rtgwg-mofrr].
This method does not work if the MRMTs merge on a common LAN with
different upstream routers. In this case, the traffic cannot be
distinguished on the LAN and will result in duplication on the LAN.
The normal PIM Assert procedure would stop one of the upstream
routers from transmitting duplicates onto the LAN once it is
detected. This, in turn, may cause the duplicate stream to be pruned
back to the source. Thus, end-to-end protection in this case of the
MRMTs converging on a single LAN with different upstream interfaces
can only be accomplished by the methods of traffic self-
identification.
4.3. Convergence Behavior
It is necessary to handle topology changes and get back to having two
MRMTs that provide global protection. To understand the requirements
and what can be computed, recall the following facts.
a. It is not generally possible to compute a single tree that is
maximally redundant to an existing tree.
b. The pair of MRTs must be computed simultaneously.
c. After a single link or node failure, there is one set of nodes
that can be reached from the root on the Blue MRMT and a second
set of nodes that can be reached from the root on the Red MRMT.
If the failure wasn't a cut-vertex or cut-edge, all nodes will be
in at least one of these two sets.
To gracefully converge, it is necessary to never have a router where
both its red MRMT and blue MRMT are broken. There are three
different ways in which this could be done. These options are being
more fully explored to see which is most practical and provides the
best set of trade-offs.
Ordered Convergence When a single failure occurs, each receiver
determines whether it was affected or unaffected. First, the
affected receivers identify the broken MRMT color (e.g. blue) and
join the MRMT via their new UMH for that MRT color. Once the
affected receivers receive confirmation that the new MRMT has been
successfully created back to the MCI, then the affected receivers
switch to using that MRMT. The affected receivers tear down the
old broken MRMT state and join the MRMT via their new UMH for the
Atlas, et al. Expires January 13, 2014 [Page 13]
Internet-Draft MRT FRR Architecture July 2013
other MRT color (e.g. red). Finally, once the affected receivers
receive confirmation that the new MRMT has been successfully
created back to the MCI, the affected receivers can tear down the
old working MRMT state. Once the affected receivers have updated
their state, the unaffected receivers need to also do the same
staging - first joining the MRMT via their new UMH for the Blue
MRT, waiting for confirmation, switching to using traffic from the
Blue MRMT, tearing down the old Blue MRMT state, joining the MRMT
via their new UMH for the Red MRT, waiting for confirmation, and
tearing down the old Red MRMT state. There are complexities
remaining, such as determining how an Unaffected Receiver decides
that the Affected Receivers are done. When the topology change
isn't a failure, all receivers are unaffected and the same process
can apply.
Protocol Make-Before-Break In the control plane, a router joins the
tree on the new Blue topology but does not stop receiving traffic
on the old Blue topology. Once traffic is observed from the new
Blue UMH, then the router accepts traffic on the new Blue UMH and
removes the old Blue UMH. This behavior can happen simultaneously
with both Blue and Red forwarding topologies. An advantage is
that it works regardless of the type of topology change and
existing traffic streams aren't broken. Another advantage is that
the complexity is limited and this method is well understood. The
disadvantage is that the number of traffic-affecting events
depends upon the number of hops to the MCI.
Multicast Source Make-Before-Break On a topology change, routers
would create new MRMTs using new MRT forwarding state and leaving
the old MRMTs as they are. After the new MRMTs are complete, the
multicast source could switch from sending on the old MRMTs to
sending on the new MRMTs. After a time, the old MRMTs could be
torn down. There are a number of details to still investigate.
4.4. Inter-area/level Behavior
A source outside of the IGP area/level can be treated as a proxy
node. When the join request reaches a border router (whether ABR for
OSPF or LBR for ISIS), that border router needs to determine whether
to use the Blue or Red forwarding topology in the next selected area/
level.
Atlas, et al. Expires January 13, 2014 [Page 14]
Internet-Draft MRT FRR Architecture July 2013
|-------------------|
| |
|---[S]---| [BR1]-----[ X ] |
| | | | |
[ A ]-----[ B ] | | |
| | [ Y ]-----[BR2]--(proxy for S)
| |
[BR1]-----[BR2] (b) Area 10
Y's Red next-hop: BR1
(a) Area 0 Y's Blue next-hop: BR2
Red Next-Hops to S
BR1's is BR2
BR2's is B
B's is S
Blue Next-Hops to S
BR1's is A
BR2's is BR1
A's is S
Figure 3: Inter-area Selection - next-hops towards S
Achieving maximally node-disjoint trees across multiple areas is hard
due to the information-hiding and abstraction. If there is only one
border router, it is trivial but protection of the border router is
not possible. With exactly 2 border routers, inter-area/level node
protection is reasonably straightforward but can require that the BR
rewrite the (S,G) for PIM. With more than 2 border routers, inter-
area node protection is possible at the cost of additional bandwidth
and border router complexity. These two solutions are described in
the following sub-sections.
4.4.1. Inter-area Node Protection with 2 border routers
If there are exactly two border routers between the areas, then the
solution and necessary computation is straightforward. In that
specific case, each BR knows that only the other BR must specifically
be avoided in the second area when a forwarding topology is selected.
As described in [I-D.enyedi-rtgwg-mrt-frr-algorithm], it is possible
for a node X to determine whether the Red or Blue forwarding topology
should be used to reach a node D while avoiding another node Y.
The results of this computation and the resulting changes in MT-ID
from Red to Blue or Blue to Red are illustrated in Figure 3. It
shows an example where BR1 must modify joins received from Area 10
for the Red MT-ID to use the Blue MT-ID in Area 0. Similarly, BR2
must modify joins received from Area 10 for the Blue MT-ID to use the
Atlas, et al. Expires January 13, 2014 [Page 15]
Internet-Draft MRT FRR Architecture July 2013
Red MT-ID in Area 0.
For mLDP, modifying the MT-ID in the control-plane is all that is
needed. For PIM, if the same (S,G) is used for both the Blue MT-ID
and the Red MT-ID, then only control-plane changes are needed.
However, for PIM, if different group IDs (e.g. G-red and G-blue) or
different source loopback addresses (S-red and S-blue) are used, it
is necessary to modify the traffic to reflect the MT-ID included in
the join message received on that interface. An alternative could be
to use an MPLS label that indicates the MT-ID instead of different
group IDs or source loopback addresses.
To summarize the necessary logic, when a BR1 receives a join from a
neighbor in area N to a destination D in area M on the Color MT-ID,
the BR1:
a. Identifies the BR2 at the other end of the proxy node in area N.
b. Determines which forwarding topology may avoid BR2 to reach D in
area M. Refer to that as Color-2 MT-ID.
c. Uses Color-2 MT-ID to determine the next-hops to S. When a join
is sent upstream, the MT-ID used is that for Color-2.
4.4.2. Inter-area Node Protection with > 2 Border Routers
If there are more than two BRs between areas, then the problem of
ensuring inter-area node-disjointness is not solved. Instead, once a
request to join the multicast tree has been received by a BR from an
area that isn't closest to the multicast source, the BR must join
both the Red MT-ID and the Blue MT-ID in the area closest to the
multicast source. Regardless of what single link or node failure
happens, each BR will receive the multicast stream. Then, the BR can
use the stream-selection techniques specified in
[I-D.ietf-rtgwg-mofrr] to pick either the Blue or Red stream and
forward it to downstream routers in the other area. Each of the BRs
for the other area should be attached to a proxy-node representing
the other area.
This approach ensures that a BR will receive the multicast stream in
the closest area as long as the single link or node failure isn't a
single point of failure. Thus, each area or level is independently
protected. The BR is required to be able to select among the
multicast streams and, if necessary for PIM, translate the traffic to
contain the correct (S,G) for forwarding.
Atlas, et al. Expires January 13, 2014 [Page 16]
Internet-Draft MRT FRR Architecture July 2013
4.5. PIM
Capabilities need to be exchanged to determine that a neighbor
supports using MRT forwarding topologies with PIM. Additional
signaling extensions are not necessary to PIM to support Global
Protection. [RFC6420] already defines how to specify an MT-ID as a
Join Attribute.
4.5.1. Traffic Handling: RPF Checks
For PIM, RPF checks would still be enabled by the control plane. The
control plane can program different forwarding entries on the G-blue
incoming interface and on the G-red incoming interface. The other
interfaces would still discard both G-blue and G-red traffic.
The receiver would still need to detect failures and handle traffic
discarding as is specified in [I-D.ietf-rtgwg-mofrr].
4.6. mLDP
Capabilities need to be exchanged to determine that a neighbor
supports using MRT forwarding topologies with mLDP. The basic
mechansims for mLDP to support multi-topology are already described
in [I-D.iwijnand-mpls-mldp-multi-topology]. It may be desirable to
extend the capability defined in this draft to indicate that MRT is
or is not supported.
5. Local Repair: Fast-Reroute
Local repair for multicast traffic is different from unicast in
several important ways.
o There is more than a single final destination. The full set of
receiving routers may not be known by the PLR and may be extremely
large. Therefore, it makes sense to repair to the immediate next-
hops for link-repair and the next-next-hops for node-repair.
These are the potential merge points (MPs).
o If a failure cannot be positively identified as a node-failure,
then it is important to repair to the immediate next-hops since
they may have receivers attached.
o If a failure cannot be positively identified as a link-failure and
node protection is desired, then it is important to repair to the
next-next-hops since they may not receive traffic from the
immediate next-hops.
Atlas, et al. Expires January 13, 2014 [Page 17]
Internet-Draft MRT FRR Architecture July 2013
o Updating multicast forwarding state may take significantly longer
than updating unicast state, since the multicast state is updated
tree by tree based on control-plane signaling.
o For tunnel-based IP/LDP approaches, neither the PLR nor the MP may
be able to specify which interface the alternate traffic will
arrive at the MP on. The simplest reason is the unicast
forwarding includes the use of ECMP and the path selection is
based upon internal router behavior for all paths between the PLR
and the MP.
For multicast fast-reroute, there are three different mechanisms that
can be used. As long as the necessary signaling is available, these
methods can be combined in the same network and even for the same PLR
and failure point.
PLR-driven Unicast Tunnels: The PLR learns the set of MPs that need
protection. On a failure, the PLR replicates the traffic and
tunnels it to each MP using the unicast route. If desired, an
RSVP-TE tunnel could be used instead of relying upon unicast
routing.
MP-driven Unicast Tunnels: Each MP learns the identity of the PLR.
Before failure, each MP independently signals to the PLR the
desire for protection and other information to use. On a failure,
the PLR replicates the traffic and tunnels it to each MP using the
unicast route. If desired, an RSVP-TE tunnel could be used
instead of relying upon unicast routing.
MP-driven Alternate Trees: Each MP learns the identity of the PLR
and the failure point (node and interface) to be protected
against. Each MP selects an upstream interface and forwarding
topology where the path will avoid the failure point; each MP
signals a join towards that upstream interface to create that
state.
Each of these options is described in more detail in their respective
sections. Then the methods are compared and contrasted for PIM and
for mLDP.
5.1. PLR-driven Unicast Tunnels
With PLR-driven unicast tunnels, the PLR learns the set of merge
points (MPs) and, on a locally detected failure, uses the existing
unicast routing to tunnel the multicast traffic to those merge
points. The failure being protected against may be link or node
failure. If unicast forwarding can provide an SRLG-protecting
alternate, then SRLG-protection is also possible.
Atlas, et al. Expires January 13, 2014 [Page 18]
Internet-Draft MRT FRR Architecture July 2013
There are five aspects to making this work.
1. PLR needs to learn the MPs and their associated MPLS labels to
create protection state.
2. Unicast routing has to offer alternates or have dedicated tunnels
to reach the MPs. The PLR encapsulates the multicast traffic and
directs it to be forwarded via unicast routing.
3. The MP must identify alternate traffic and decide when to accept
and forward it or drop it.
4. When the MP reconverges, it must move to its new UMH using make-
before-break so that traffic loss is minimized.
5. The PLR must know when to stop sending traffic on the alternates.
5.1.1. Learning the MPs
If link-protection is all that is desired, then the PLR already knows
the identities of the MPs. For node-protection, this is not
sufficient. In the PLR-driven case, there is no direct communication
possible between the PLR and the next-next-hops on the multicast
tree. (For mLDP, when targeted LDP sessions are used, this is
considered to be MP-driven and is covered in Section 5.2.)
In addition to learning the identities of the MPs, the PLR must also
learn the MPLS label, if any, associated with each MP. For mLDP, a
different label should be supplied for the alternate traffic; this
allows the MP to distinguish between the primary and alternate
traffic. For PIM, an MPLS label is used to identify that traffic is
the alternate. The unicast tunnel used to send traffic to the MP may
have penultimate-hop-popping done; thus without an explicit MPLS
label, there is no certainty that a packet could be conclusively
identified as primary traffic or as alternate traffic.
A router must tell its UMH the identity of all downstream multicast
routers, and their associated alternate labels, on the particular
multicast tree. This clearly requires protocol extensions. The
extensions for PIM are given in [I-D.kebler-pim-mrt-protection].
5.1.2. Using Unicast Tunnels and Indirection
The PLR must encapsulate the multicast traffic and tunnel it towards
each MP. The key point is how that traffic then reaches the MP.
There are basically two possibilities. It is possible that a
dedicated RSVP-TE tunnel exists and can be used to reach the MP for
just this traffic; such an RSVP-TE tunnel would be explicitly routed
Atlas, et al. Expires January 13, 2014 [Page 19]
Internet-Draft MRT FRR Architecture July 2013
to avoid the failure point. The second possibility is that the
packet is tunneled via LDP and uses unicast routing. The second case
is explored here.
It is necessary to assume that unicast LDP fast-reroute
[I-D.ietf-rtgwg-mrt-frr-architecture][RFC5714][RFC5286] is supported
by the PLR. Since multicast convergence takes longer than unicast
convergence, the PLR may have two different routes to the MP over
time. When the failure happens, the PLR will have an alternate,
whether LFA or MRT, to reach the MP. Then the unicast routing
converges and the PLR will have a new primary route to the MP. Once
the routing has converged, it is important that alternate traffic is
no longer carried on the MRT forwarding topologies. This rule allows
the MRT forwarding topologies to reconverge and be available for the
next failure. Therefore, it is also necessary for the tunneled
multicast traffic to move from the alternate route to the new primary
route when the PLR reconverges. Therefore, the tunneled multicast
traffic should use indirection to obtain the unicast routing's
current next-hops to the MP. If physical indirection is not
feasible, then when the unicast LIB is updated, the associated
multicast alternate tunnel state should be as well.
When the PLR detects a local failure, the PLR replicates each
multicast packet, swaps or adds the alternate MPLS label needed by
the MP, and finally pushes the appropriate label for the MP based
upon the outgoing interface selected by the unicast routing.
For PIM, if no alternate labels are supplied by the MPs, then the
multicast traffic could be tunneled in IP. This would require
unicast IP fast-reroute.
5.1.3. MP Alternate Traffic Handling
A potential Merge Point must determine when and if to accept
alternate traffic. There are two critical components to this
decision. First, the MP must know the state of all links to its UMH.
This allows the MP to determine whether the multicast stream could be
received from the UMH. Second, the MP must be able to distinguish
between a normal multicast tree packet and an alternate packet.
The logic is similar for PIM and mLDP, but in PIM there is only one
RPF-interface or interface of interest to the UMH. In mLDP, all the
directly connected interfaces to the UMH are of interest. When the
MP detects a local failure, if that interface was the last connected
to the UMH and used for the multicast group, then the MP must rapidly
switch from accepting the normal multicast tree traffic to accepting
the alternate traffic. This rapid change must happen within the same
approximately 50 milliseconds that the PLR switching to send traffic
Atlas, et al. Expires January 13, 2014 [Page 20]
Internet-Draft MRT FRR Architecture July 2013
on the alternate takes and for the same reasons. It does no good for
the PLR to send alternate traffic if the MP doesn't accept it when it
is needed.
The MP can identify alternate traffic based upon the MPLS label.
This will be the alternate label that the MP supplied to its UMH for
this purpose.
5.1.4. Merge Point Reconvergence
After a failure, the MP will want to join the multicast tree
according to the new topology. It is critical that the MP does this
in a way that minimizes the traffic disruption. Whenever paths
change, there is also the possibility for a traffic-affecting event
due to different latencies. However, traffic impact above that
should be avoided.
The MP must do make-before-break. Until the MP knows that its new
UMH is fully connected to the MCI, the MP should continue to accept
its old alternate traffic. The MP could learn that the new UMH is
sufficient either via control-plane mechanisms or data-driven. In
the latter case, the reception of traffic from the new UMH can
trigger the change-over. If the data-driven approach is used, a
time-out to force the switch should apply to handle multicast trees
that have long quiet periods.
5.1.5. PLR termination of alternate traffic
The PLR sends traffic on the alternates for a configurable time-out.
There is no clean way for the next-hop routers and/or next-next-hop
routers to indicate that the traffic is no longer needed.
If better control were desired, each MP could tell its UMH what the
desired time-out is. The UMH could forward this to the PLR as well.
Then the PLR could send alternate traffic to different MPs based upon
the MP's individual timer. This would only be an advantage if some
of the MPs were expected to have a longer multicast reconvergence
time than others - either due to load or router capabilities.
5.2. MP-driven Unicast Tunnels
MP-driven unicast tunnels are only relevant for mLDP where targeted
LDP sessions are feasible. For PIM, there is no mechanism to
communicate beyond a router's immediate neighbors; these techniques
could work for link-protection, but even then there would not be a
way of requesting that the PLR should stop sending traffic.
There are three differences for MP-driven unicast tunnels from PLR-
Atlas, et al. Expires January 13, 2014 [Page 21]
Internet-Draft MRT FRR Architecture July 2013
driven unicast tunnels.
1. The MPs learn the identity of the PLR from their UMH. The PLR
does not learn the identities of the MPs.
2. The MPs create direct connections to the PLR and communicate
their alternate labels.
3. When the MPs have converged, each explicitly tells the PLR to
stop sending alternate traffic.
The first means that a router communicates its UMH to all its
downstream multicast hops. Then each MP communicates to the PLR(s)
(1 for link-protection and 1 for node-protection) and indicates the
multicast tree that protection is desired for and the associated
alternate label.
When the PLR learns about a new MP, it adds that MP and associated
information to the set of MPs to be protected. On a failure, the PLR
does the same behavior as for the PLR-driven unicast tunnels.
After the failure, the MP reconverges using make-before-break. Then
the MP explicitly communicates to the PLR(s) that alternate traffic
is no longer needed for that multicast tree. When the node-
protecting PLR hasn't changed for a MP, it may be necessary to
withdraw the old alternate label, which tells the PLR to stop
transmitting alternate traffic, and then provide a new alternate
label.
5.3. MP-driven Alternate Trees
In this document we have defined different solutions to achieve fast
convergence for multicast link and node protection based on MRTs. At
a high level these solutions can be separated in Local and Global
protections. Alternate Trees, which is a Local protection schema,
initially looked like an attractive solution for Multicast node
protection since it avoids replicating the packet by the PLR to each
of the receivers of the protected node and waisting bandwidth.
However, this comes at the expense of extra multicast state and
complexity. In order to mitigate the extra multicast state its
possible to aggregate the Alternate Trees by creating an Alternate
Tree per protected node and reuse it for all the multicast trees
going through this node. This further complicates the procedures and
upstream assigned labels are required to de-aggregate the trees.
With aggregation we are also introducing an unwanted side effect.
The receiver population of the aggregated trees will very likely not
be the same. That means multicast packets will be forwarded on the
Alternate Tree to node(s) that may not have a receiver(s) for the
Atlas, et al. Expires January 13, 2014 [Page 22]
Internet-Draft MRT FRR Architecture July 2013
protected tree. The more protected trees are aggregated, the higher
the risk of forwarding unwanted multicast packets, this leads again
to waisting bandwidth.
Considering the complexity of this solution and the unwanted side-
effects, the authors of this document believe its better to solve
Multicast node protection using a Global protection schema, as
documented in Section 4. The solution previously defined in this
section has been move to Appendix A (Section 9).
6. Acknowledgements
The authors would like to thank Kishore Tiruveedhula, Santosh Esale,
and Maciek Konstantynowicz for their suggestions and review.
7. IANA Considerations
This doument includes no request to IANA.
8. Security Considerations
This architecture is not currently believed to introduce new security
concerns.
9. Appendix A
9.1. MP-driven Alternate Trees
For some networks, it is highly desirable not to have the PLR perform
replication to each MP. PLR replication can cause substantial
congestion on links used by alternates to different MPs. At the same
time, it is also desirable to have minimal extra state created in the
network. This can be resolved by creating alternate-trees that can
protect multiple multicast groups as a bypass-alternate-tree. An
alternate-tree can also be created per multicast group, PLR and
failure point.
It is not possible to merge alternate-trees for different PLRs or for
different neighbors. This is shown in Figure 4 where G can't select
an acceptable upstream node on the alternate tree that doesn't
violate either the need to avoid C (for PLR A) or D (for PLR B).
Atlas, et al. Expires January 13, 2014 [Page 23]
Internet-Draft MRT FRR Architecture July 2013
|-------[S]--------| Alternate from A must avoid C
V V Alternate from B ust avoid D
[A]------[E]-------[B]
| | |
V | V
|--[C]------[F]-------[D]---|
| | | |
| |-------[G]--------| |
| | |
| | |
|->[R1]-----[H]-------[R2]<-|
(a) Multicast tree from S
S->A->C->R1 and S->B->D->R2
Figure 4: Alternate Trees from PLR A and B can't be merged
A MP that joins an alternate-tree for a particular multicast stream
should not expect or request PLR-replicated tunneled alternate
traffic for that same multicast stream.
Each alternate-tree is identified by the PLR which sources the
traffic and the failure point (node and link) (FP) to be avoided.
Different multicast groups with the same PLR and FP may have
different sets of MPs - but they are all at most going to include the
FP (for link protection) and the neighbors of FP except for the PLR.
For a bypass-alternate-tree to work, it must be acceptable to
temporarily send a multicast group's traffic to FP's neighbors that
do not need it. This is the trade-off required to reduce alternate-
tree state and use bypass-alternate-trees. As discussed in
Section 5.1.3, a potential MP can determine whether to accept
alternate traffic based upon the state of its normal upstream links.
Alternate traffic for a group the MP hasn't joined can just be
discarded.
[S]......[PLR]--[ A ]
| | |
1| |2 |
[ FP]--[MP3]
| \ |
| \ |
[MP1]--[MP2]
Figure 5: Alternate Tree Scenario
Atlas, et al. Expires January 13, 2014 [Page 24]
Internet-Draft MRT FRR Architecture July 2013
For any router, knowing the PLR and the FP to avoid will force
selection of either the Blue MRT or the Red MRT. It is possible that
the FP doesn't actually appear in either MRT path, but the FP will
always be in either the set of nodes that might be used for the Blue
MRT path or the set of nodes that might be used for the Red MRT path.
The FP's membership in one of the sets is a function of the partial
ordering and topological ordering created by the MRT algorithm and is
consistent between routers in the network graph.
To create an alternate-tree, the following must happen:
1. For node-protection, the MP learns from its upstream (the FP) the
node-id of its upstream (the PLR) and, optionally, a link
identifier for the link used to the PLR. The link-id is only
needed for traffic handling in PIM, since mLDP can have targeted
sessions between the MP and the PLR.
2. For link-protection, the MP needs to know the node-id of its
upstream (the PLR) and, optionally, its identifier for the link
used to the PLR.
3. The MP determines whether to use the Blue or Red forwarding
topology to reach the PLR while avoiding the FP and associated
interface. This gives the MP its alternate-tree upstream
interface.
4. The MP signals a backup-join to its alternate-tree upstream
interface. The backup-join specifies the PLR, FP and, for PIM,
the FP-PLR link identifier. If the alternate-tree is not to be
used as a bypass-alternate-tree, then the multicast group (e.g.
(S,G) or Opaque-Value) must be specified.
5. A router that receives a backup-join and is not the PLR needs to
create multicast state and send a backup-join towards the PLR on
the appropriate Blue or Red forwarding topology as is locally
determined to avoid the FP and FP-PLR link.
6. Backup-joins for the same (PLR, FP, PLR-FP link-id) that
reference the same multicast group can be merged into a single
alternate-tree. Similarly, backup-joins for the same (PLR, FP,
PLR-FP link-id) that reference no multicast group can be merged
into a single alternate-tree.
7. When the PLR receives the backup-join, it associates either the
specified multicast group with that alternate-tree, if such is
given, or associates all multicast groups that go to the FP via
the specified FP-PLR link with the alternate-tree.
Atlas, et al. Expires January 13, 2014 [Page 25]
Internet-Draft MRT FRR Architecture July 2013
For an example, look at Figure 5. FP would send a backup-join to MP3
indicating (PLR, FP, PLR-FP link-1). MP3 sends a backup-join to A.
MP1 sends a backup-join to MP2 and MP2 sends a backup-join to MP3.
It is necessary that traffic on each alternate-tree self-identify as
to which alternate-tree it is part of. This is because an alternate-
tree for a multicast-group and a particular (PLR, FP, PLR-FP link-id)
can easily overlap with an alternate-tree for the same multicast
group and a different (PLR, FP, PLR-FP link-id). The best way of
doing this depends upon whether PIM or mLDP is being used.
9.1.1. PIM details for Alternate-Trees
For PIM, the (S,G) of the IP packet is a globally unique identifier
and is understood. To identify the alternate-tree, the most
straightforward way is to use MPLS labels distributed in the PIM
backup-join messages. A MP can use the incoming label to indicate
the set of RPF-interfaces for which the traffic may be an alternate.
If the alternate-tree isn't a bypass-alternate-tree, then only one
RPF interface is referenced. If the alternate-tree is a bypass-
alternate-tree, then multiple RPF-interfaces (parallel links to FP)
might be intended. Alternate-tree traffic may cross an interface
multiple times - either because the interface is a broadcast
interface and different downstream-assigned labels are provided
and/or because a MP may provide different labels.
9.1.2. mLDP details for Alternate-Trees
For mLDP, if bypass-alternate-trees are used, then the PLR must
provide upstream-assigned labels to each multicast stream. The MP
provides the label for the alternate-tree; if the alternate-tree is
not a bypass-alternate-tree, this label also describes the multicast
stream. If the alternate-tree is a bypass-alternate-tree, then it
provides the context for the PLR-assigned labels for each multicast
stream. If there are targeted LDP sessions between the PLR and the
MPs, then the PLR could provide the necessary upstream-assigned
labels.
9.1.3. Traffic Handling by PLR
An issue with traffic is how long should the PLR continue to send
alternate traffic out. With an alternate-tree, the PLR can know to
stop forwarding alternate traffic on the alternate-tree when that
alternate-tree's state is torn down. This provides a clear signal
that alternate traffic is no longer needed.
Atlas, et al. Expires January 13, 2014 [Page 26]
Internet-Draft MRT FRR Architecture July 2013
9.2. Methods Compared for PIM
The two approaches that are feasible for PIM are PLR-driven Unicast
Tunnels and MP-driven Alternate-Trees.
+-------------------------+-------------------+---------------------+
| Aspect | PLR-driven | MP-driven |
| | Unicast Tunnels | Alternate-Trees |
+-------------------------+-------------------+---------------------+
| Worst-case Traffic | 1 + number of MPs | 2 |
| Replication Per Link | | |
| PLR alternate-traffic | timer-based | control-plane |
| | | terminated |
| Extra multicast state | none | per (PLR,FP,S) for |
| | | bypass mode |
+-------------------------+-------------------+---------------------+
Which approach is prefered may be network-dependent. It should also
be possible to use both in the same network.
9.3. Methods Compared for mLDP
All three approaches are feasible for mLDP. Below is a brief
comparison of various aspects of each.
+-------------------+---------------+-------------+-----------------+
| Aspect | MP-driven | PLR-driven | MP-driven |
| | Unicast | Unicast | Alternate-Trees |
| | Tunnels | Tunnels | |
+-------------------+---------------+-------------+-----------------+
| Worst-case | 1 + number of | 1 + number | 2 |
| Traffic | MPs | of MPs | |
| Replication Per | | | |
| Link | | | |
| PLR | control-plane | timer-based | control-plane |
| alternate-traffic | terminated | | terminated |
| Extra multicast | none | none | per (PLR,FP,S) |
| state | | | for bypass mode |
+-------------------+---------------+-------------+-----------------+
10. References
10.1. Normative References
[I-D.enyedi-rtgwg-mrt-frr-algorithm]
Atlas, A., Envedi, G., Csaszar, A., and A. Gopalan,
"Algorithms for computing Maximally Redundant Trees for
Atlas, et al. Expires January 13, 2014 [Page 27]
Internet-Draft MRT FRR Architecture July 2013
IP/LDP Fast- Reroute",
draft-enyedi-rtgwg-mrt-frr-algorithm-03 (work in
progress), July 2013.
[I-D.ietf-rtgwg-mrt-frr-architecture]
Atlas, A., Kebler, R., Envedi, G., Csaszar, A., Tantsura,
J., Konstantynowicz, M., White, R., and M. Shand, "An
Architecture for IP/LDP Fast-Reroute Using Maximally
Redundant Trees", draft-ietf-rtgwg-mrt-frr-architecture-03
(work in progress), July 2013.
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601, August 2006.
[RFC6388] Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas,
"Label Distribution Protocol Extensions for Point-to-
Multipoint and Multipoint-to-Multipoint Label Switched
Paths", RFC 6388, November 2011.
[RFC6420] Cai, Y. and H. Ou, "PIM Multi-Topology ID (MT-ID) Join
Attribute", RFC 6420, November 2011.
10.2. Informative References
[I-D.ietf-rtgwg-mofrr]
Karan, A., Filsfils, C., Farinacci, D., Wijnands, I.,
Decraene, B., Joorde, U., and W. Henderickx, "Multicast
only Fast Re-Route", draft-ietf-rtgwg-mofrr-02 (work in
progress), June 2013.
[I-D.iwijnand-mpls-mldp-multi-topology]
Wijnands, I. and K. Raza, "mLDP Extensions for Multi
Topology Routing",
draft-iwijnand-mpls-mldp-multi-topology-03 (work in
progress), June 2013.
[I-D.kebler-pim-mrt-protection]
Kebler, R., Atlas, A., Wijnands, IJ., and G. Enyedi, "PIM
Extensions for Protection Using Maximally Redundant
Trees", draft-kebler-pim-mrt-protection-00 (work in
progress), March 2012.
[I-D.wijnands-mpls-mldp-node-protection]
Wijnands, I., Rosen, E., Raza, K., Tantsura, J., Atlas,
A., and Q. Zhao, "mLDP Node Protection",
draft-wijnands-mpls-mldp-node-protection-04 (work in
progress), June 2013.
Atlas, et al. Expires January 13, 2014 [Page 28]
Internet-Draft MRT FRR Architecture July 2013
[RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast
Reroute: Loop-Free Alternates", RFC 5286, September 2008.
[RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework",
RFC 5714, January 2010.
Authors' Addresses
Alia Atlas (editor)
Juniper Networks
10 Technology Park Drive
Westford, MA 01886
USA
Email: akatlas@juniper.net
Robert Kebler
Juniper Networks
10 Technology Park Drive
Westford, MA 01886
USA
Email: rkebler@juniper.net
IJsbrand Wijnands
Cisco Systems, Inc.
Email: ice@cisco.com
Andras Csaszar
Ericsson
Konyves Kalman krt 11
Budapest 1097
Hungary
Email: Andras.Csaszar@ericsson.com
Atlas, et al. Expires January 13, 2014 [Page 29]
Internet-Draft MRT FRR Architecture July 2013
Gabor Sandor Enyedi
Ericsson
Konyves Kalman krt 11.
Budapest 1097
Hungary
Email: Gabor.Sandor.Enyedi@ericsson.com
Atlas, et al. Expires January 13, 2014 [Page 30]