Protocol Independent Multicast Working Group R. Kebler, Ed.
Internet-Draft A. Atlas
Intended status: Standards Track Juniper Networks
Expires: January 13, 2014 N. Shen
Cisco Systems, Inc.
Y. Cai
Microsoft
July 12, 2013
PIM Extensions for Protection Using Maximally Redundant Trees
draft-kebler-pim-mrt-protection-01
Abstract
This document specifies Protocol Independent Multicast (PIM)
procedures for Failure Protection, as specified in the MRT Multicast
architecture [I-D.atlas-rtwg-mrt-mc-arch]. This can be accomplished
with Global Repair (aka Live-Live) or with Local Repair (aka Fast Re-
route). Maximally Redundant Trees (MRTs) provide the capability to
PIM to provide alternate paths around any given failure.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 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
Kebler, et al. Expires January 13, 2014 [Page 1]
Internet-Draft PIM Protection using MRTs July 2013
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Global Protection (Live-Live) . . . . . . . . . . . . . . . . 4
3.1. Egress Router Behavior . . . . . . . . . . . . . . . . . 4
3.2. Limitation when a LAN is a cut-link . . . . . . . . . . . 4
3.3. Using Different Groups to identify MRTs . . . . . . . . . 5
4. Local Protection . . . . . . . . . . . . . . . . . . . . . . 5
4.1. PLR Replication . . . . . . . . . . . . . . . . . . . . . 5
4.1.1. PLR Behavior . . . . . . . . . . . . . . . . . . . . 6
4.1.2. Unicast convergence during PLR Replication . . . . . 6
4.1.3. MP Behavior . . . . . . . . . . . . . . . . . . . . . 6
4.1.4. Downstream Routers from the MP . . . . . . . . . . . 7
4.1.5. Protected Node Behavior . . . . . . . . . . . . . . . 7
5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Hello Options . . . . . . . . . . . . . . . . . . . . . . 8
5.1.1. MRT Protection Capabilities . . . . . . . . . . . . . 8
5.2. Join Attributes . . . . . . . . . . . . . . . . . . . . . 9
5.2.1. Merge Point Attribute . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction
This document specifies how to reduce traffic loss after network
failures by using Maximally Redundant Trees (MRTs). This can be
accomplished with Global Repair (aka Live-Live) or with Local Repair
(aka Fast Re-route). The tradeoffs and applicability for each method
of protection are discussed in the MRT Multicast architecture
[I-D.atlas-rtwg-mrt-mc-arch].
With Global Repair, a multicast egress will send PIM Joins for the
same stream on multiple MRT topologies. The Global Repair specified
in this document is similar to [I-D.ietf-rtgwg-mofrr]. This document
specifies how this can be accomplished using MRTs, however, providing
100% coverage without requiring any particular network topology.
Kebler, et al. Expires January 13, 2014 [Page 2]
Internet-Draft PIM Protection using MRTs July 2013
Local Repair for Link or Node protection can also be used to protect
Multicast traffic. A Point of Local Repair (PLR) can replicate the
traffic to all Merge Points (MPs). In order to accomplish this, the
PLR must know the unicast destination of all MPs. Upon the failure,
the PLR will send the traffic to all MPs.
2. Terminology
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.
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.
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.
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.
Kebler, et al. Expires January 13, 2014 [Page 3]
Internet-Draft PIM Protection using MRTs July 2013
MT-ID: Multi-topology identifier
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 as described in
[I-D.ietf-rtgwg-mofrr].
MultiCast Egress (MCE): Multicast Egress, a node where the
multicast stream exists the current PIM domain. This is usually a
receiving router that may forward the multicast traffic towards
receivers based upon IGMP or other technology.
3. Global Protection (Live-Live)
In order to achieve Global Protection, traffic will flow through the
network through disjoint paths. A multicast egress (MCE) router will
trigger this traffic flow by sending PIM joins on two different
interfaces. The MRT algorithm will ensure that these joins travel
through maximally disjoint paths to the source. The egress router
must then forward a single stream along to its downstream members.
Any failure in the network to either stream can be repaired by this
egress router, since it is receiving the redundant stream.
Any router that is capable of supporting Global Repair with MRTs must
advertise the T bit in the MRT Protection Hello Option.
3.1. Egress Router Behavior
A multicast egress (MCE) router will join a multicast stream on both
the Blue and Red MRT. The MT-ID [RFC6420] of the MRT will be
included in the Join as a Join Attribute [RFC5384]. Traffic will
flow down both MRTs to the egress router to achieve redundancy. The
egress router will forward a single stream along to its downstream
interfaces. The techniques for this stream selection are described
in MoFRR [I-D.ietf-rtgwg-mofrr].
3.2. Limitation when a LAN is a cut-link
There is a limitation in end-to-end protection when, for a given S,G,
the MRTs converge on a single LAN with different upstream neighbors.
In this case, both upstream neighbors will be sending on the LAN, and
there is no distinguishing the data traffic for the different MRTs if
it is carried with the same S,G. The PIM Assert procedures will
select a single forwarding router on the LAN and the other router
will stop sending. This could cause the Assert Loser to prune back
the S,G. Therefore, traffic will flow on only one MRT between the
source and the downstream router on the LAN.
Kebler, et al. Expires January 13, 2014 [Page 4]
Internet-Draft PIM Protection using MRTs July 2013
3.3. Using Different Groups to identify MRTs
There may be cases when different sources or groups are used to send
the same stream, as decribed in the MRT Multicast architecture
[I-D.atlas-rtwg-mrt-mc-arch]. In this case the egress router may not
need to perform the stream selection. However, it would be desirable
for the egress router to join the sources or groups on different
MRTS. The mechanism to perform group to MRT mapping is outside the
scope of this document. Once the egress router knows the group to
MRT mapping, then it will join for the S,G on the particular tree by
including the MT-ID for the MRT in the Join message. In this case,
the streams can travel across the same LAN without the issues
described above.
4. Local Protection
Local Protection can protect either a link or node, and this will be
determined on a per flow basis. A Join Attribute will be used for
downstream routers to signal the Merge Point information. Each
router will advertise in its MRT Protection Hello Options whether it
is capable of performing Link or Node protection.
4.1. PLR Replication
At a PLR, each S,G flow will have a set of downstream interfaces and
a set of MPs for each downstream interface. There will be MPLS label
information learned for each MP. Upon a failure to the protected
link, the PLR will encapsulate and send the protected multicast
traffic to all MPs for that particlar (S,G,intf). The MP will,
therefore, receive the encapsulated data upon the failure and traffic
will resume to all of its downstream receivers. Once the PLR has
given the downstream routers sufficient time to recover from the
failure, it can stop sending the protected traffic, and prune
upstream, if required.
For the PLR to send the protected traffic upon a failure, it requires
the unicast address and an MPLS label (which may be Implicit Null)
for all the Merge Points. Each MP will advertise this information in
a Merge Point Join Attribute. If link protection is used, this is
sufficient to reach the PLR. For node protection, the information
for all MPs will be sent to the PLR in a Join Attribute from the
upstream node of the MP (i.e., the Protected Node). In this case,
the MP will set the N bit in these Join Attributes to indicate the
Protected Node needs to send the Join Attribute upstream to the PLR.
If the MP or the Protecting Node is sending the Join attribute to the
PLR, it will set the P bit in the Join Attribute.
Kebler, et al. Expires January 13, 2014 [Page 5]
Internet-Draft PIM Protection using MRTs July 2013
All routers that support this functionality will advertise the Link
or Node capability bits in the MRT Protection Hello Option. Any Node
that is capable of acting as a PLR will advertise the PLR-Replication
capable bit in the MRT Protection Hello Option.
4.1.1. PLR Behavior
The PLR will learn the location of all the MPs in the its Join
Messages that it receives from downstream routers. The Merge Points
will be kept per (S,G, downstream-interface). Upon a failure to the
protected interface, the PLR will encapsulate and forward the
multicast data to all the MPs for that downstream interface, and it
will start the Alternate-Tree-Protection-Timer. The Alternate-Tree-
Protection-Timer should be a configurable timer with a default of 10
seconds. The PLR will suppress the PIM Prunes from being sent while
the Protection-Timer is running. Once this timer expires, it will
stop sending the traffic to MPs, and it can send a Prune upstream if
required.
For a PLR to learn of all MPs, then Join Suppression must be disabled
on the interfaces between the MP and the PLR. In addition, the PLR
must accept all MP ID Join Attributes that it receives from
downstream neighbors.
4.1.2. Unicast convergence during PLR Replication
Since it is likely for unicast routes to converge before PIM fully
converges, the PLR must still be able to route the traffic to all MPs
while unicast recovers from the original failure. The PLR must not
use stale forwarding information to reach the MPs for the protected
multicast traffic if unicast has already updated it forwarding
entries after the network event. An implementation should use the
same forwarding information that would be used to forward unicast
traffic to that destination. In this way, the PLR will be able to
forward traffic to the MPs.
4.1.3. MP Behavior
As is done today, the MP will forward traffic received on its normal
incoming interface. While the normal RPF interface is up,
encapulated alternate traffic will not be forwarded. If the RPF
interface fails, the MP will forward the encapulated alternate
traffic (if it is received with the correct encapsulation). This
procedure assumes that there is a method for the routers on both
sides of the protected link to determine if the link has gone down.
Such methods are outside the scope of this document.
Kebler, et al. Expires January 13, 2014 [Page 6]
Internet-Draft PIM Protection using MRTs July 2013
After the incoming interface changes the MP will start the Alternate-
Tree-Protection-Timer. Once traffic arrives on the new incoming
interface or the Alternate-Tree-Protection-Timer expires, the Merge
Point will advertise the label for the new RPF interface in the Merge
Point Join Attribute, and it will stop accepting the encapsulated
alternate traffic.
The MP needs to know when it can release the label that it has
advertised and potentially re-use that label for another purpose. If
the interface goes down or the adjacency goes down on an interface
that the MP was advertising a label, it should wait JP_Holdtime for
link protection and (2 * JP_Holdtime) for node protection before re-
using that label for any other purpose.
4.1.4. Downstream Routers from the MP
Some make-before-break techniques should be used on routers
downstream from the failure to ensure that traffic is not discarded
once these routers learn of the unicast change. For example, if a
downstream router, upon a unicast route change, prunes itself off its
old RPF interface and discards traffic until the new tree is formed
back to the source, then there will be end-to-end loss. The work
that the upstream routers did to repair the local failure will be
wasted since the downstream router is going to discard flowing
traffic. The make-before-breaks procedures needed on the downstream
router is outside the scope of this document.
4.1.5. Protected Node Behavior
Kebler, et al. Expires January 13, 2014 [Page 7]
Internet-Draft PIM Protection using MRTs July 2013
For Node Protection, the MP will be one hop away from the Protected
Node and two hops away from the PLR. In this case, there may be
multiple next-next-hops to advertise as Merge Points in the Join
Attribute. The Protected Node will learn the downstream members and
it will gather the MP information from each downstream neighbor's
Merge Point Join Attribute. For each Merge Point in the downstream
list, the Protected Node will include a Merge Point Join Attribute in
the Join that is sent upstream to the PLR. These Join attributes
must have the N bit cleared when they are sent to the PLR. The PLR
will add a Merge Point attribute for its own information to include
itself as a Merge Point. All the Join attributes will have the P bit
set, indicating they are being sent to a PLR. The Merge Point
information may change for a route entry before the JoinPrune would
normally be updated or refreshed to the PLR. Upon a change to the
next-next hop list, the router can send a triggered JoinPrune with
the updated Join Attribute, or it can wait for the next periodic
refresh. It would be a tradeoff of increased control messages
against a window of being unprotected. For a PLR to learn of all
MPs, then Join Suppression must be disabled on the interfaces between
the MP and the PLR.
5. Packet Formats
5.1. Hello Options
5.1.1. MRT Protection Capabilities
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = TBD | Length = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rsvd |P|T|L|N|
+-+-+-+-+-+-+-+-+
MRT Protection Hello Option Format
Type: TBD.
Length: 1
Rsvd: Sent with 0, ignored on receipt
Kebler, et al. Expires January 13, 2014 [Page 8]
Internet-Draft PIM Protection using MRTs July 2013
P: PLR Replication capable. This bit is set if a router is
capable of acting as a PLR-replicating router, as described in
this document. This router must also be capable of receiving a
Merge Point Join Attribute.
T: MRT Topology Capable. This bit is set if the router is
capable of understanding MRT topology IDs sent in the MT-ID
Join Attribute [RFC5384], as defined in this document.
L: Link Protection Capable. This bit is set if the router is
capable of performing Link Protection, as defined in this
document. This router must also be capable of receiving a
Merge Point Join Attribute.
N: Node Protection. This bit is set if the router is capable
of performing Node Protection, as defined in this document.
This router must also be capable of receiving a Merge Point
Join Attribute.
5.2. Join Attributes
5.2.1. Merge Point Attribute
The following Join attribute is used for local protection, when the
Protected-Node needs to signal the Merge Point information to the
PLR. There will be a separate Merge Point Attribute for each Merge
Point being advertised for the source. This attribute should only be
sent to routers that are Link or Node capable, as advertised in the
MRT Protection Hello Option.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|E| Type | Length |N|P| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Merge Point Join Attribute
F-bit: This bit will be clear as this is a non-transitive
attribute.
Kebler, et al. Expires January 13, 2014 [Page 9]
Internet-Draft PIM Protection using MRTs July 2013
E-bit: As defined in [RFC5384]
Type: TBD
Length field: variable
N bit - This Label is for a node-protecting MP. The label and
this Join attribute will need to be sent upstream (to the PLR) in
the upstream Join message. When sending this Join attribute
upstream, this bit MUST be cleared.
P bit - This bit indicates that the receiving router should act as
a PLR. This bit should only be set in Joins to routers that are
PLR-Replication capable, as advertised in the MRT Protection Hello
Option
Reserved: Sent with zero, ignored on receipt
label: the MPLS label associated with this MP
MP: The encoded-Unicast addresses of the Merge Point
6. IANA Considerations
A new PIM Hello Option type is requested to assign to the MRT
Protection Hello Option
A new PIM Join Attribute Type is requested for the Merge Point Join
Attribute
7. Security Considerations
There are no security considerations for this design other than what
is already in the main PIM specification [RFC4601] .
8. References
8.1. Normative 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.
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601, August 2006.
Kebler, et al. Expires January 13, 2014 [Page 10]
Internet-Draft PIM Protection using MRTs July 2013
[RFC5384] Boers, A., Wijnands, I., and E. Rosen, "The Protocol
Independent Multicast (PIM) Join Attribute Format", RFC
5384, November 2008.
[RFC6395] Gulrajani, S. and S. Venaas, "An Interface Identifier (ID)
Hello Option for PIM", RFC 6395, October 2011.
[RFC6420] Cai, Y. and H. Ou, "PIM Multi-Topology ID (MT-ID) Join
Attribute", RFC 6420, November 2011.
8.2. Informative References
[I-D.atlas-rtwg-mrt-mc-arch]
Atlas, A., Kebler, R., Wijnands, IJ., and G. Enyedi, "An
Architecture for Multicast Protection Using Maximally
Redundant Trees", atlas-rtwg-mrt-mc-arch-02 (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-02
(work in progress), February 2013.
Authors' Addresses
Robert Kebler (editor)
Juniper Networks
10 Technology Park Drive
Westford, MA 01886
USA
Email: rkebler@juniper.net
Alia Atlas
Juniper Networks
10 Technology Park Drive
Westford, MA 01886
USA
Email: akatlas@juniper.net
Kebler, et al. Expires January 13, 2014 [Page 11]
Internet-Draft PIM Protection using MRTs July 2013
Naiming Shen
Cisco Systems, Inc.
170 W. Tasman Drive
San Jose, CA 95134
USA
Email: naiming@cisco.com
Yiqun Cai
Microsoft
La Avenida
Mountain View, CA 94043
USA
Email: yiqunc@microsoft.com
Kebler, et al. Expires January 13, 2014 [Page 12]