One document matched: draft-atlas-rtgwg-mrt-mc-arch-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC4601 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4601.xml">
<!ENTITY RFC5286 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5286.xml">
<!ENTITY RFC5714 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5714.xml">
<!ENTITY RFC5715 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5715.xml">
<!ENTITY RFC6388 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6388.xml">
<!ENTITY RFC6420 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6420.xml">
<!ENTITY I-D.ietf-rtgwg-mofrr SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-rtgwg-mofrr.xml">
<!ENTITY I-D.ietf-rtgwg-mrt-frr-architecture SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-rtgwg-mrt-frr-architecture.xml">
<!ENTITY I-D.enyedi-rtgwg-mrt-frr-algorithm SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.enyedi-rtgwg-mrt-frr-algorithm.xml">
<!ENTITY I-D.iwijnand-mpls-mldp-multi-topology SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.iwijnand-mpls-mldp-multi-topology.xml">
<!ENTITY I-D.wijnands-mpls-mldp-node-protection SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.wijnands-mpls-mldp-node-protection.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="no" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-atlas-rtgwg-mrt-mc-arch-01" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="MRT FRR Architecture">An Architecture for Multicast Protection Using Maximally Redundant Trees</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Alia Atlas" initials="A.K.A." role="editor" surname="Atlas">
<organization>Juniper Networks</organization>
<address>
<postal>
<street>10 Technology Park Drive</street>
<city>Westford</city>
<region>MA</region>
<code>01886</code>
<country>USA</country>
</postal>
<email>akatlas@juniper.net</email>
</address>
</author>
<author fullname="Robert Kebler" initials="R.K." surname="Kebler">
<organization>Juniper Networks</organization>
<address>
<postal>
<street>10 Technology Park Drive</street>
<city>Westford</city>
<region>MA</region>
<code>01886</code>
<country>USA</country>
</postal>
<email>rkebler@juniper.net</email>
</address>
</author>
<author fullname="IJsbrand Wijnands" initials="IJ.W." surname="Wijnands">
<organization>Cisco Systems, Inc.</organization>
<address>
<email>ice@cisco.com</email>
</address>
</author>
<!--
<author fullname="Yiqun Cai" initials="Y.C." surname="Cai">
<organization>Cisco Systems, Inc.</organization>
<address>
<email>yai@cisco.com</email>
</address>
</author>
-->
<author fullname="András Császár" initials="A.C." surname="Császár">
<organization>Ericsson</organization>
<address>
<postal>
<street>Konyves Kalman krt 11</street>
<city>Budapest</city>
<country>Hungary</country>
<code>1097</code>
</postal>
<email>Andras.Csaszar@ericsson.com</email>
</address>
</author>
<author fullname="Gábor Sándor Enyedi" initials="G.S.E." surname="Enyedi">
<organization>Ericsson</organization>
<address>
<postal>
<street>Konyves Kalman krt 11.</street>
<city>Budapest</city>
<country>Hungary</country>
<code>1097</code>
</postal>
<email>Gabor.Sandor.Enyedi@ericsson.com</email>
</address>
</author>
<date year="2013" />
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>Routing</area>
<workgroup>Routing Area Working Group</workgroup>
<abstract>
<t>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).</t>
<t>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.</t>
<t>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.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>This document describes how the algorithms in <xref
target="I-D.enyedi-rtgwg-mrt-frr-algorithm"/>, which are used in
<xref target="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<xref target="RFC4601"/> or mLDP<xref
target="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.</t>
<t>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 <xref
target="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.</t>
<t>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.</t>
<t><list style="symbols">
<t>Global 1+1 Protection Using PIM</t>
<t>Global 1+1 Protection Using mLDP</t>
<t>Local Protection Using mLDP: <xref
target="I-D.wijnands-mpls-mldp-node-protection"/>This document
describes how to provide node-protection and the necessary
extensions using targeted LDP session.</t>
<t>Local Protection Using PIM</t>
</list></t>
<section title="Maximally Redundant Trees (MRTs)">
<t>Maximally Redundant Trees (MRTs) are described in <xref
target="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 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).</t>
<t>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 <xref
target="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.</t>
<figure anchor="mrt_example" align="center"
title="A network and two MRTs found in it">
<artwork align="center"><![CDATA[
[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
]]></artwork>
</figure>
<t>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
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. </t>
<t>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.</t>
<t>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.</t>
</section>
<section title="MRTs and Multicast">
<t>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.</t>
<t>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 <xref
target="I-D.enyedi-rtgwg-mrt-frr-algorithm"/>.</t>
</section>
</section><!-- End of Introduction !-->
<section title="Terminology">
<t><list style="hanging">
<t hangText="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.</t>
<t hangText="2-connected cluster: ">A maximal set of nodes that
are 2-connected.</t>
<t hangText="2-edge-connected: ">A network graph where at least
two links must be removed to partition the network.</t>
<t hangText="ADAG: ">Almost Directed Acyclic Graph - a graph
that, if all links incoming to the root were removed, would be a
DAG.</t>
<t hangText="block: ">Either a 2-connected cluster, a cut-edge,
or an isolated vertex.</t>
<t hangText="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. </t>
<t hangText="cut-vertex: ">A vertex whose removal partitions the
network.</t>
<t hangText="DAG: ">Directed Acyclic Graph - a graph where all
links are directed and there are no cycles in it.</t>
<t hangText="GADAG: ">Generalized ADAG - a graph that is
the combination of the ADAGs of all blocks.</t>
<t hangText="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.</t>
<t hangText="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.</t>
<t hangText="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.</t>
<t hangText="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.</t>
<t hangText="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.</t>
<t hangText="Point of Local Repair (PLR): ">The router that
detects a local failure and decides whether and when to forward
traffic on appropriate alternates.</t>
<t hangText="MT-ID: ">Multi-topology identifier. The default
shortest-path-tree topology is MT-ID 0.</t>
<t hangText="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.</t>
<t hangText="Upstream Multicast Hop (UMH): ">Upstream Multicast
Hop, a candidate next-hop that can be used to reach the MCI of
the tree.</t>
<t hangText="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 <xref target="I-D.ietf-rtgwg-mofrr"/>.</t>
<t hangText="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.</t>
</list></t>
</section>
<section title="Use-Cases and Applicability">
<t>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.</t>
<t><list style="symbols">
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
</list></t>
<t>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.</t>
<t>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.</t>
</section>
<section title="Global Protection: Multicast Live-Live">
<t>In MoFRR <xref target="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 <xref target="I-D.ietf-rtgwg-mofrr"/>. For other networks,
it is still desirable to have two disjoint multicast trees and allow a
receiver to join both and make its own decision about which traffic to
accept.</t>
<t>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.</t>
<t>There are four different aspects of using MRTs for 1+1 Global
Protection that are necessary to consider. They are as follows.</t>
<t><list style="numbers">
<t>Creation of the maximally redundant multicast trees (MRMTs) based
upon the forwarding topologies.</t>
<t>Traffic Identification: How to handle traffic when the two MRMTs overlap
due to a cut-vertex or cut-link.</t>
<t>Convergence: How to converge after a network change and get back to
a protected state.</t>
<t>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.</t>
</list></t>
<section title="Creation of MRMTs">
<t>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.</t>
<t><list style="numbers">
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
</list></t>
</section>
<section title="Traffic Self-Identification">
<t>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 <xref target="mrt_example"/> and repeated below in <xref
target="repeat_mrt_example"/>, where there are two cut-vertices C and
G and a cut-link C<->G. </t>
<figure anchor="repeat_mrt_example" align="center"
title="A network and two MRTs found in it">
<artwork align="center"><![CDATA[
[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
]]></artwork>
</figure>
<t>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.</t>
<t><list style="hanging">
<t hangText="mLDP: ">Different label bindings will be created for the
Blue and Red MRMTs. As specified in <xref
target="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.</t>
<t hangText="PIM: ">There are three different ways to handle IP traffic
forwarded based upon PIM when that traffic will overlap on a link.
<list style="letters">
<t>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.</t>
<t>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.</t>
<t>Stream Selection and Merging: The third option, described in <xref
target="merge_mrmts"/>, 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.</t>
</list></t>
</list></t>
<t>There are three options presented for PIM. The most appropriate
will depend upon deployment scenario as well as router capabilities.</t>
<section anchor="merge_mrmts"
title="Merging MRMTs for PIM if Traffic Doesn't Self-Identify">
<t>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).</t>
<t>The behavior described in this section differs from the conflict
resolution described in <xref target="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.</t>
<t>As described in <xref target="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 <xref target="RFC6420"/>, the router must send a
Join upstream for each MT-ID. If a 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 <xref
target="I-D.ietf-rtgwg-mofrr"/>.</t>
<t>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.</t>
</section>
</section>
<section title="Convergence Behavior">
<t>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.
<list style="letters">
<t>It is not generally possible to compute a single tree that is
maximally redundant to an existing tree.</t>
<t>The pair of MRTs must be computed simultaneously.</t>
<t>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.</t>
</list>
</t>
<t>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.
<list style="hanging">
<t hangText="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 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.</t>
<t hangText="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.</t>
<t hangText="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.</t>
</list></t>
</section>
<section title="Inter-area/level Behavior">
<t>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.</t>
<figure anchor="fig_intarea" align="center"
title="Inter-area Selection - next-hops towards S">
<artwork align="center"><![CDATA[
|-------------------|
| |
|---[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
]]></artwork>
</figure>
<t>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.</t>
<section title="Inter-area Node Protection with 2 border routers">
<t>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 <xref target="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.</t>
<t>The results of this computation and the resulting changes in MT-ID
from Red to Blue or Blue to Red are illustrated in <xref
target="fig_intarea"/>. 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 Red MT-ID in Area 0.</t>
<t>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.</t>
<t>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:</t>
<t><list style="letters">
<t>Identifies the BR2 at the other end of the proxy node in area N.</t>
<t>Determines which forwarding topology may avoid BR2 to reach D in
area M. Refer to that as Color-2 MT-ID.</t>
<t>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.</t>
</list></t>
</section>
<section title="Inter-area Node Protection with > 2 Border Routers">
<t>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 <xref
target="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.</t>
<t>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.</t>
</section>
</section>
<section title="PIM">
<t>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. <xref target="RFC6420"/> already defines how to specify
an MT-ID as a Join Attribute.</t>
<section title="Traffic Handling: RPF Checks">
<t>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.</t>
<t>The receiver would still need to detect failures and handle traffic
discarding as is specified in <xref target="I-D.ietf-rtgwg-mofrr"/>.</t>
</section>
</section>
<section title="mLDP">
<t>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
<xref target="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.</t>
</section>
</section>
<section title="Local Repair: Fast-Reroute">
<t>Local repair for multicast traffic is different from unicast in
several important ways.</t>
<t><list style="symbols">
<t>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).</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
</list></t>
<t>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.</t>
<t><list style="hanging">
<t hangText="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.</t>
<t hangText="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.</t>
<t hangText="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.</t>
</list></t>
<t>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.</t>
<section title="PLR-driven Unicast Tunnels">
<t>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.</t>
<t>There are five aspects to making this work.</t>
<t><list style="numbers">
<t>PLR needs to learn the MPs and their associated MPLS labels to
create protection state.</t>
<t>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.</t>
<t>The MP must identify alternate traffic and decide when to accept
and forward it or drop it.</t>
<t>When the MP reconverges, it must move to its new UMH using
make-before-break so that traffic loss is minimized.</t>
<t>The PLR must know when to stop sending traffic on the alternates.</t>
</list></t>
<section title="Learning the MPs">
<t>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 <xref
target="mp_driven_ucast_tunnels"/>.)</t>
<t>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.</t>
<t>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 <xref
target="I-D.kebler-pim-mrt-protection"/>.</t>
</section>
<section title="Using Unicast Tunnels and Indirection">
<t>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
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.</t>
<t>It is necessary to assume that unicast LDP fast-reroute <xref
target="I-D.ietf-rtgwg-mrt-frr-architecture"/><xref
target="RFC5714"/><xref target="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.</t>
<t>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.</t>
<t>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.</t>
</section>
<section anchor="sec_mp_traffic_handling" title="MP Alternate Traffic Handling">
<t>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.</t>
<t>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
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.</t>
<t>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.</t>
</section>
<section title="Merge Point Reconvergence">
<t>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.</t>
<t>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.</t>
</section>
<section title="PLR termination of alternate traffic">
<t>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. </t>
<t>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.</t>
</section>
</section>
<section anchor="mp_driven_ucast_tunnels" title="MP-driven Unicast Tunnels">
<t>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.</t>
<t>There are three differences for MP-driven unicast tunnels from
PLR-driven unicast tunnels.</t>
<t><list style="numbers">
<t>The MPs learn the identity of the PLR from their UMH. The PLR does
not learn the identities of the MPs.</t>
<t>The MPs create direct connections to the PLR and communicate their alternate labels.</t>
<t>When the MPs have converged, each explicitly tells the PLR to stop
sending alternate traffic.</t>
</list></t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
</section>
<section title="MP-driven Alternate Trees">
<t>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.</t>
<t>It is not possible to merge alternate-trees for different PLRs or
for different neighbors. This is shown in <xref
target="fig_alt_tree_no_merge"/> 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).</t>
<figure anchor="fig_alt_tree_no_merge" align="center"
title="Alternate Trees from PLR A and B can't be merged">
<artwork align="center"><![CDATA[
|-------[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
]]></artwork>
</figure>
<t>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.</t>
<t>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 <xref
target="sec_mp_traffic_handling"/>, 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.</t>
<figure anchor="fig_alt_tree" align="center"
title="Alternate Tree Scenario">
<artwork align="center"><![CDATA[
[S]......[PLR]--[ A ]
| | |
1| |2 |
[ FP]--[MP3]
| \ |
| \ |
[MP1]--[MP2]
]]></artwork>
</figure>
<t>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.</t>
<t>To create an alternate-tree, the following must happen:</t>
<t><list style="numbers">
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
</list></t>
<t>For an example, look at <xref target="fig_alt_tree"/>. 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.</t>
<t>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.</t>
<section title="PIM details for Alternate-Trees">
<t>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.</t>
</section>
<section title="mLDP details for Alternate-Trees">
<t>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.</t>
</section>
<section title="Traffic Handling by PLR">
<t>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.</t>
</section>
</section>
<section title="Methods Compared for PIM">
<t>The two approaches that are feasible for PIM are PLR-driven Unicast
Tunnels and MP-driven Alternate-Trees.</t>
<texttable>
<ttcol align='center'>Aspect</ttcol>
<ttcol align='center'>PLR-driven Unicast Tunnels</ttcol>
<ttcol align='center'>MP-driven Alternate-Trees</ttcol>
<c>Worst-case Traffic Replication Per Link</c> <c>1 + number of MPs</c> <c>2</c>
<c>PLR alternate-traffic</c> <c>timer-based</c> <c>control-plane terminated</c>
<c>Extra multicast state</c> <c>none</c> <c>per (PLR,FP,S) for bypass mode</c>
</texttable>
<t>Which approach is prefered may be network-dependent. It should
also be possible to use both in the same network.</t>
</section>
<section title="Methods Compared for mLDP">
<t>All three approaches are feasible for mLDP. Below is a brief
comparison of various aspects of each.</t>
<texttable>
<ttcol align='center'>Aspect</ttcol>
<ttcol align='center'>MP-driven Unicast Tunnels</ttcol>
<ttcol align='center'>PLR-driven Unicast Tunnels</ttcol>
<ttcol align='center'>MP-driven Alternate-Trees</ttcol>
<c>Worst-case Traffic Replication Per Link</c> <c>1 + number of MPs</c>
<c>1 + number of MPs</c> <c>2</c>
<c>PLR alternate-traffic</c> <c>control-plane terminated</c>
<c>timer-based</c> <c>control-plane terminated</c>
<c>Extra multicast state</c> <c>none</c> <c>none</c> <c>per (PLR,FP,S) for bypass mode</c>
</texttable>
</section>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The authors would like to thank Kishore Tiruveedhula, Santosh
Esale, and Maciek Konstantynowicz for their suggestions and review.</t>
</section>
<!-- Possibly a 'Contributors' section ... -->
<section anchor="IANA" title="IANA Considerations">
<t>This doument includes no request to IANA.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>This architecture is not currently believed to introduce new
security concerns.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
&RFC6388;
&I-D.enyedi-rtgwg-mrt-frr-algorithm;
&I-D.ietf-rtgwg-mrt-frr-architecture;
&RFC6420;
&RFC4601;
</references>
<references title="Informative References">
&I-D.ietf-rtgwg-mofrr;
&RFC5714;
&RFC5286;
&I-D.iwijnand-mpls-mldp-multi-topology;
&I-D.wijnands-mpls-mldp-node-protection;
<reference anchor="I-D.kebler-pim-mrt-protection">
<front>
<title>PIM Extensions for Protection Using Maximally Redundant Trees</title>
<author fullname="Robert Kebler" initials="R.K." surname="Kebler"/>
<author fullname="Alia Atlas" initials="A.A." surname="Atlas"/>
<author fullname="IJsbrand Wijnands" initials="IJ.W." surname="Wijnands"/>
<author fullname="Gabor Sandor Enyedi" initials="G.S.E." surname="Enyedi"/>
<date year="2012" month="March"/>
</front>
<seriesInfo name=""
value="draft-kebler-pim-mrt-protection-00 (work in progress)" />
</reference>
</references>
<!-- Change Log
v00 2012-02-09 AKA Initial version based off old combined arch
-->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 17:44:02 |