draft-ietf-rtgwg-mofrr-01.txt   draft-ietf-rtgwg-mofrr-02.txt 
Network Working Group A. Karan Network Working Group A. Karan
Internet-Draft C. Filsfils Internet-Draft C. Filsfils
Intended status: Informational D. Farinacci Intended status: Informational D. Farinacci
Expires: October 20, 2013 IJ. Wijnands, Ed. Expires: December 21, 2013 IJ. Wijnands, Ed.
Cisco Systems, Inc. Cisco Systems, Inc.
B. Decraene B. Decraene
France Telecom France Telecom
U. Joorde U. Joorde
Deutsche Telekom Deutsche Telekom
W. Henderickx W. Henderickx
Alcatel-Lucent Alcatel-Lucent
April 18, 2013 June 19, 2013
Multicast only Fast Re-Route Multicast only Fast Re-Route
draft-ietf-rtgwg-mofrr-01 draft-ietf-rtgwg-mofrr-02
Abstract Abstract
As IPTV deployments grow in number and size, service providers are As IPTV deployments grow in number and size, service providers are
looking for solutions that minimize the service disruption due to looking for solutions that minimize the service disruption due to
faults in the IP network carrying the packets for these services. faults in the IP network carrying the packets for these services.
This draft describes a mechanism for minimizing packet loss in a This draft describes a mechanism for minimizing packet loss in a
network when node or link failures occur. Multicast only Fast Re- network when node or link failures occur. Multicast only Fast Re-
Route (MoFRR) works by making simple enhancements to multicast Route (MoFRR) works by making simple enhancements to multicast
routing protocols such as PIM and mLDP. routing protocols such as PIM and mLDP.
skipping to change at page 1, line 44 skipping to change at page 1, line 44
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 20, 2013. This Internet-Draft will expire on December 21, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 29 skipping to change at page 2, line 29
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Upstream Multicast Hop Selection . . . . . . . . . . . . . . . 4 3. Upstream Multicast Hop Selection . . . . . . . . . . . . . . . 4
3.1. PIM . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. PIM . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. mLDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. mLDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Topologies for MoFRR . . . . . . . . . . . . . . . . . . . . . 5 4. Topologies for MoFRR . . . . . . . . . . . . . . . . . . . . . 5
4.1. Dual-Plane Topology . . . . . . . . . . . . . . . . . . . 5 4.1. Dual-Plane Topology . . . . . . . . . . . . . . . . . . . 5
5. Detecting Failures . . . . . . . . . . . . . . . . . . . . . . 8 5. Detecting Failures . . . . . . . . . . . . . . . . . . . . . . 8
6. ECMP-mode MoFRR . . . . . . . . . . . . . . . . . . . . . . . 9 6. ECMP-mode MoFRR . . . . . . . . . . . . . . . . . . . . . . . 9
7. Non-ECMP-mode MoFRR . . . . . . . . . . . . . . . . . . . . . 9 7. Non-ECMP-mode MoFRR . . . . . . . . . . . . . . . . . . . . . 9
7.1. Variation . . . . . . . . . . . . . . . . . . . . . . . . 11 8. Keep It Simple Principle . . . . . . . . . . . . . . . . . . . 10
8. Keep It Simple Principle . . . . . . . . . . . . . . . . . . . 11
9. Capacity Planning for MoFRR . . . . . . . . . . . . . . . . . 11 9. Capacity Planning for MoFRR . . . . . . . . . . . . . . . . . 11
10. Other Applications . . . . . . . . . . . . . . . . . . . . . . 12 10. Other Applications . . . . . . . . . . . . . . . . . . . . . . 11
11. Security Considerations . . . . . . . . . . . . . . . . . . . 12 11. Security Considerations . . . . . . . . . . . . . . . . . . . 12
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
13. Contributing authors . . . . . . . . . . . . . . . . . . . . . 13 13. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 12
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
14.1. Normative References . . . . . . . . . . . . . . . . . . . 13 14.1. Normative References . . . . . . . . . . . . . . . . . . . 12
14.2. Informative References . . . . . . . . . . . . . . . . . . 13 14.2. Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
Multiple techniques have been developed and deployed to improve Multiple techniques have been developed and deployed to improve
service guarantees, both for multicast video traffic and Video on service guarantees, both for multicast video traffic and Video on
Demand traffic. Most existing solutions are geared towards finding Demand traffic. Most existing solutions are geared towards finding
an alternate path around one or more failed network elements (link, an alternate path around one or more failed network elements (link,
node, path failures). node, path failures).
skipping to change at page 4, line 11 skipping to change at page 4, line 11
UMH : Upstream Multicast Hop, a candidate next-hop that can be used UMH : Upstream Multicast Hop, a candidate next-hop that can be used
to reach the root of the tree. to reach the root of the tree.
tree : Either a PIM (S,G)/(*,G) tree or a mLDP P2MP or MP2MP LSP. tree : Either a PIM (S,G)/(*,G) tree or a mLDP P2MP or MP2MP LSP.
OIF : Outgoing InterFace, an interface used to forward multicast OIF : Outgoing InterFace, an interface used to forward multicast
packets down the tree towards the receivers. Either a PIM packets down the tree towards the receivers. Either a PIM
(S,G)/(*,G) tree or a mLDP P2MP or MP2MP LSP. (S,G)/(*,G) tree or a mLDP P2MP or MP2MP LSP.
LFA : Loop Free Alternate, a candidate UMH that can be used for the
secondary MoFRR path.
2. Basic Overview 2. Basic Overview
The basic idea of MoFRR is for a merge point router to join a The basic idea of MoFRR is for a merge point router to join a
multicast tree via two divergent upstream paths in order to get multicast tree via two divergent upstream paths in order to get
maximum redundancy. The two divergent paths SHOULD never merge maximum redundancy. The two divergent paths SHOULD never merge
upstream, otherwise the maximal redundancy is compromised. Sometimes upstream, otherwise the maximal redundancy is compromised. Sometimes
the topology guarantees maximal redundancy, other times additional the topology guarantees maximal redundancy, other times additional
configuration or techniques are needed to enforce it. See later in configuration or techniques are needed to enforce it. See later in
this document. this document.
skipping to change at page 8, line 45 skipping to change at page 8, line 45
PE1----PE2 PE1----PE2
FIG3. PEs are connected in pairs to Dual-Plane Backbone FIG3. PEs are connected in pairs to Dual-Plane Backbone
5. Detecting Failures 5. Detecting Failures
Once the two paths are established, the next step is detecting a Once the two paths are established, the next step is detecting a
failure on the primary path to know when to switch to the backup failure on the primary path to know when to switch to the backup
path. path.
A first option consists of comparing the packets received on the The first (and simplest) option to detect a path failure is if a
directly connected link that is used as MoFRR UMH goes down. This
option can be used in combination with the other options as
documented below. 50msec switchover is possible.
A second option consists of comparing the packets received on the
primary and secondary streams but only forwarding one of them -- the primary and secondary streams but only forwarding one of them -- the
first one received, no matter which interface it is received on. first one received, no matter which interface it is received on.
Zero packet loss is possible for RTP-based streams. Zero packet loss is possible for RTP-based streams.
A second option assumes a minimum known packet rate for a given data A third option assumes a minimum known packet rate for a given data
stream. If a packet is not received on the primary RPF within this stream. If a packet is not received on the primary RPF within this
time frame, the router assumes primary path failure and switches to time frame, the router assumes primary path failure and switches to
the secondary RPF interface. 50msec switchover is possible. the secondary RPF interface. 50msec switchover is possible.
A third option leverages the significant improvements of the IGP A fourth option leverages the significant improvements of the IGP
convergence speed. When the primary path to the source is withdrawn convergence speed. When the primary path to the source is withdrawn
by the IGP, the MoFRR-enabled router switches over to the backup by the IGP, the MoFRR-enabled router switches over to the backup
path, the UMH is changed to the secondary UMH. Since the secondary path, the UMH is changed to the secondary UMH. Since the secondary
path is already in place, and assuming it is disjoint from the path is already in place, and assuming it is disjoint from the
primary path, convergence times would not include the time required primary path, convergence times would not include the time required
to build a new tree and hence are smaller. Realistic availability to build a new tree and hence are smaller. Realistic availability
requirements (sub-second to sub-200msec) should be possible. requirements (sub-second to sub-200msec) should be possible.
A fourth option consists in leveraging connected link failure. This
option makes sense when MoFRR is deployed across the network (not
only at PE).
6. ECMP-mode MoFRR 6. ECMP-mode MoFRR
If the IGP installs two ECMP paths to the source and if the Multicast If the IGP installs two ECMP paths to the source and if the Multicast
tree is enabled for ECMP-Mode MoFRR, the router installs them as tree is enabled for ECMP-Mode MoFRR, the router installs them as
primary and secondary UMH. Only packets received from the primary primary and secondary UMH. Only packets received from the primary
UMH path are processed. Packets received from the secondary UMH are UMH path are processed. Packets received from the secondary UMH are
dropped. dropped.
The selected primary UMH should be the same as if MoFRR extension was The selected primary UMH should be the same as if MoFRR extension was
not enabled. not enabled.
skipping to change at page 10, line 16 skipping to change at page 10, line 16
/ \ / \
Backbone Backbone
| | | |
| | | |
| | | |
X--------N X--------N
Fig5. Non-ECMP-Mode MoFRR Fig5. Non-ECMP-Mode MoFRR
X is configured for MoFRR for a Multicast tree X is configured for MoFRR for a Multicast tree
R(X) is Xs UMH to S R(X) is the primary UMH to S for X
N is a neighbor of X N is a neighbor of X
R(N) is Ns UMH to S R(N) is the LFA UMH to S for X
xs represents the IGP metric from X to S
ns represents the IGP metric from N to S
xn represents the IGP metric from X to N
A router X configured for non-ECMP-mode MoFRR for a Multicast tree Router X in FIG5 has one primary path R(X) and one secondary LFA path
R(N) to reach the source. How it is determined that N is a LFA path
from X to S follows the procedures as documented in [RFC5286]. A
router X configured for non-ECMP-mode MoFRR for a Multicast tree
joins a primary path to its primary UMH R(X) and a secondary path to joins a primary path to its primary UMH R(X) and a secondary path to
UMH N if the following three conditions are met. LFA UMH N. Router X MUST stop joining the seconday path if the
following as described below occurs;
C1: xs < xn + ns
C2: ns < nx + xs
C3: X cannot join the secondary path N if N is the only member of the OIF list
The first condition ensures that N is not on the primary branch from
X to S.
The second condition ensures that X is not on the primary branch from
N to S.
These two conditions ensure that at least locally the two paths are
disjoint.
The third condition is required to break control-plane loops which
could occur in some scenarios.
For example in FIG3, if PE1 and PE2 have received an igmp request for
a Multicast tree, they will both join the primary path on their plane
and a secondary path to the neighbor PE. If their receivers would
leave at the same time, it could be possible for the Multicast tree
on PE1 and PE2 to never get deleted as each PE refresh each other via
the secondary path joins (remember that a secondary path join is not
distinguishable from a primary join. MoFRR does not require any PIM
or mLDP protocol modification).
A control-plane loop occurs when two nodes keep a state forever due
to joining the secondary path to each other. This forever condition
is not acceptable as no real receiver is connected to the nodes
(directly via IGMP or indirectly via PIM). Rule 3 prevents this case
as it prevents the mutual refresh of secondary joins and it applies
it in the specific case where there is no real receiver connected.
7.1. Variation
Rule R3 can be removed if Rule 2 is restricted as follows:
R2p: ns < xs
This ensures that X will only join the secondary path to a neighbor N
who is strictly closer to the source than X is. By reciprocity, N
will thus never join the secondary path for the same Multicast tree
via X. The strictly smaller than is key here.
Note that this non-ECMP-mode MoFRR variation does not support the Consider the example in FIG3, if PE1 and PE2 have received an igmp
square topology and hence is less preferred. request for a Multicast tree, they will both join the primary path on
their plane and a secondary path to the neighbor PE. If their
receivers would leave at the same time, it could be possible for the
Multicast tree on PE1 and PE2 to never get deleted as each PE refresh
each other via the secondary path joins (remember that a secondary
path join is not distinguishable from a primary join). In order to
prevent control-plane loops a router MUST never setup a secondary
path to a LFA UMH if this UMH is the only member in the OIF list.
8. Keep It Simple Principle 8. Keep It Simple Principle
Many Service Providers devise their topology such that PEs have Many Service Providers devise their topology such that PEs have
disjoint paths to the multicast sources. MoFRR leverages the disjoint paths to the multicast sources. MoFRR leverages the
existence of these disjoint paths without any PIM or mLDP protocol existence of these disjoint paths without any PIM or mLDP protocol
modification. Interoperability testing is thus not required. In modification. Interoperability testing is thus not required. In
such topologies, MoFRR only needs to be deployed on the PE devices. such topologies, MoFRR only needs to be deployed on the PE devices.
Each PE device can be enabled one by one. PEs not enabled for MoFRR Each PE device can be enabled one by one. PEs not enabled for MoFRR
do not see any change or degradation. do not see any change or degradation.
skipping to change at page 13, line 10 skipping to change at page 12, line 21
There are no security considerations for this design other than what There are no security considerations for this design other than what
is already in the main PIM specification [RFC4601] and mLDP is already in the main PIM specification [RFC4601] and mLDP
specification [RFC6388] . specification [RFC6388] .
12. Acknowledgments 12. Acknowledgments
The authors would like to thank John Zwiebel, Greg Shepherd and Dave The authors would like to thank John Zwiebel, Greg Shepherd and Dave
Oran for their review of the draft. Oran for their review of the draft.
13. Contributing authors 13. Contributor Addresses
Below is a list of other contributing authors in alphabetical order: Below is a list of other contributing authors in alphabetical order:
Nicolai Leymann Nicolai Leymann
Deutsche Telekom Deutsche Telekom
Winterfeldtstrasse 21 Winterfeldtstrasse 21
Berlin 10781 Berlin 10781
DE DE
Email: N.Leymann@telekom.de Email: N.Leymann@telekom.de
Jeff Tantsura
Ericsson
300 Holger Way
San Jose CA 95134
USA
14. References 14. References
14.1. Normative References 14.1. Normative References
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP
Specification", RFC 5036, October 2007. Specification", RFC 5036, October 2007.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast
Reroute: Loop-Free Alternates", RFC 5286, September 2008.
14.2. Informative References 14.2. Informative References
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM): "Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601, August 2006. Protocol Specification (Revised)", RFC 4601, August 2006.
[RFC6388] Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas, [RFC6388] Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas,
"Label Distribution Protocol Extensions for Point-to- "Label Distribution Protocol Extensions for Point-to-
Multipoint and Multipoint-to-Multipoint Label Switched Multipoint and Multipoint-to-Multipoint Label Switched
Paths", RFC 6388, November 2011. Paths", RFC 6388, November 2011.
skipping to change at page 14, line 45 skipping to change at page 14, line 18
BE BE
Email: ice@cisco.com Email: ice@cisco.com
Bruno Decraene Bruno Decraene
France Telecom France Telecom
38-40 rue du General Leclerc 38-40 rue du General Leclerc
Issy Moulineaux cedex 9, 92794 Issy Moulineaux cedex 9, 92794
FR FR
Email: bruno.decraene@orange-ftgroup.com Email: bruno.decraene@orange.com
Uwe Joorde Uwe Joorde
Deutsche Telekom Deutsche Telekom
Hammer Str. 216-226 Hammer Str. 216-226
Muenster D-48153 Muenster D-48153
DE DE
Email: Uwe.Joorde@telekom.de Email: Uwe.Joorde@telekom.de
Wim Henderickx Wim Henderickx
Alcatel-Lucent Alcatel-Lucent
 End of changes. 21 change blocks. 
72 lines changed or deleted 50 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/