MPLS Working Group Pranjal Kumar Dutta
Internet Draft Wim Henderickx
Intended status: Informational Alcatel-Lucent
Expires: January 2012 July 4, 2011
Upstream LSR Redundancy for Multi-point LDP Tunnels
draft-pdutta-mpls-mldp-up-redundancy-00.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on January 4, 2012.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
Dutta, et al. Expires January 4, 2012 [Page 1]
Internet-Draft mLdp Upstream Redundancy July 2011
Abstract
Label Distribution Protocol (LDP) can be used to set up Point-to-
Multipoint (P2MP) and Multipoint-to-Multipoint (MP2MP) Label Switched
Paths. The existing specification for this functionality assumes that
a downstream LSR selects only one upstream LSR for a P2MP or MP2MP
LSP. A Make-Before-Break (MBB) procedure in mLdp base specification
[MLDP] for graceful upstream LSR change but that is not applicable
when the upstream LSR node fails. As IPTV deployments grow in number
and size, service providers are looking for solutions that minimize
the service disruption due to such failures. This document describes
a set of procedures that minimize packet loss when an upstream LSR
node fails. This document does not change any specifications of mLdp
protocol as defined in [MLDP] and so there are no inter-operability
requirements for the procedures described in this document.
Table of Contents
1. Introduction...................................................2
1.1. Problem Statement.........................................2
2. Conventions used in this document..............................3
3. Terminology....................................................3
4. Upstream LSR Redundancy........................................4
5. Backup Upstream LSR Selection..................................5
5.1 Equal-Cost-Multi-Path (ECMP).............................5
5.2 Loop-Free-Alternate (LFA).............................6
6. Fast Failover to Backup Upstream LSR...........................7
7. Security Considerations........................................7
8. IANA Considerations............................................7
9. References.....................................................8
9.1. Normative References......................................8
9.2. Informative References....................................8
10. Acknowledgments...............................................8
1. Introduction
1.1. Problem Statement
The Label Distribution Protocol (LDP) extensions for setting up
Point-to-Multipoint (P2MP) Label Switched Paths (LSPs) and
Multipoint-to-Multipoint (MP2MP) LSPs are specified in [mLdp]. This
set of extensions is generally known as "Multipoint LDP" (mLdp) and
this documents refer P2MP and MP2MP LSPs as "mLdp Tunnels", unless
specified otherwise.
Dutta, et al. Expires January 4, 2012 [Page 2]
Internet-Draft mLdp Upstream Redundancy July 2011
A node Z that wants to join an mLdp Tunnel determines the upstream
peer U which is Z's next-hop on the best path from Z to the root node
R of the mLdp tunnel. If there is more than one such LDP peer due to
Equal-Cost-Multi-Path (ECMP), only one of them is picked. As defined
in [MLDP] when there are several candidate upstream LSRs, the LSR Z
must select only one upstream LSR based on a localized selection
algorithm at node Z.
When the best path to reach the root changes, the mLdp tunnel may be
broken temporarily resulting in packet loss until the LSR Z re-
converges to a new upstream LSR U'. A set of Make-Before-Break (MBB)
procedures is defined in [MLDP] for graceful transition to new
upstream LSR U' and thus minimize this traffic loss. However these
set of procedures are not applicable when upstream LSR U fails and
that results in loss of traffic till topology re-converges to new
upstream U' and Z completes set-up of new path towards the root. mLdp
tunnels carry loss sensitive traffic such as broadcast video so it is
very important to provide protection against such upstream node
failures. A router's IGP convergence time is generally on the order
of hundred's of milliseconds; the application traffic may be
sensitive to losses greater than tens of milliseconds till the local
LSR selects new upstream LSR and establishes the mLdp tunnel path
towards the root node.
Minimizing traffic loss requires a mechanism for the local LSR Z on
detection of failure to its immediate upstream U to rapidly invoke a
repair path, which is minimally affected by any subsequent re-
convergence. This document describes a set of procedures to provide
protection against failure of upstream LSR by pre-establishing an
mLdp tunnel path to one or more secondary upstream LSRs. The
specification in this document leverage existing methodologies to
achieve upstream LSR failover protection without imposing
requirements on inter-operability or new protocol specification.
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC-2119].
3. Terminology
Primary Upstream : Upstream LSR chosen by a node to receive traffic
on an mLdp tunnel.
Dutta, et al. Expires January 4, 2012 [Page 3]
Internet-Draft mLdp Upstream Redundancy July 2011
Backup Upstream : Redundant Upstream LSR chosen by a node to receive
traffic on an mLdp tunnel on failure of its
primary upstream.
ECMP : Equal Cost Multi-Path
LFA : Loop-Free-Alternates
4. Upstream LSR Redundancy
Upstream LSR failure protection can be provided by taking advantage
of redundant topologies in service provider networks. A local LSR Z
selects two upstream LSRs - one primary LSR U and at least one backup
LSR U'. Label mappings L sent to U and L' sent to U shares the same
downstream next-hop label forwarding entries at Z. It needs to be
ensured that mLdp tunnel path along such secondary LSR U' is loop
free. Data packets are received by Z from both U and U'
simultaneously. Redundant packets received from U' are discarded by
Z. When Z detects a reachability failure to U then it switches its
upstream to the backup LSR U' and packets are immediately available
to forward out of each downstream next-hops. The amount of traffic
loss in such failovers is dependent on the detection methodologies
used by Z to detect failure of U. Details of such methodologies are
out of scope of this document.
This mode of upstream LSR protection causes traffic replication from
U' to Z which is dropped at Z. Note that such traffic replication
does may demand extra capacity although on failure of U, the mLdp
tunnel would have converged to U' anyway as a result of network
topology change. In service provider networks it is likely that such
redundant paths are kept disjoint from fate sharing. Redundant
replications may not require additional capacity in the network, but
may change replication distribution in upstream router U'.
This method is simple and is localize to individual routers along the
path from root to leaves of an mLdp tunnels. There arises no inter-
operability requirements since there is no change in mLdp protocol
operation. End-to-end failure protection and recovery can be achieved
by such localized protection at every node.
Dutta, et al. Expires January 4, 2012 [Page 4]
Internet-Draft mLdp Upstream Redundancy July 2011
5. Backup Upstream LSR Selection
Backup upstream LSR protection is highly dependent on topology, that
is on the existence of two disjoint paths from LSR Z performing
protection to the root node R of the mLdp tunnel.
Upstream LSR Protection works best for following topologies:
5.1 Equal-Cost-Multi-Path (ECMP)
R
... ...
| |
+-----+ +-----+
| U' | | U |
+-+---+ +-----+
| |
| 4 4 | |
| | | \|/
\|/ | |
| +-----+ |
+----| Z |---+
+--+--+
|
|
| 10
|
+----------+----------+
| |
+--+--+ +--+--+
|Leaf | | Leaf|
+-----+ +-----+
Figure 1.
If the IGP installs ECMP paths at node Z to the Root Node R of the
mLdp tunnel, then Z selects one primary upstream LSR U based on
procedures in [MLDP]. If there are other LDP peers with remaining
paths in ECMP then Z can select one or more of those peers as backup
upstream LSR U' and label mappings are sent to those peers. Packets
received from backup upstream LSRs are dropped locally at Z till
primary upstream U fails. Since the packets from U' are already
arriving at Z so Z can switchover to U' immediately on detection of
failure to U. Further ECMP also means loop-free so on failure of U,
Dutta, et al. Expires January 4, 2012 [Page 5]
Internet-Draft mLdp Upstream Redundancy July 2011
this does not cause any loop in the path of the mLdp tunnel through
U' from root node R towards the leaves.
5.2 Loop-Free-Alternate (LFA)
It is possible that in service provider network there are several
loop free alternate paths exist. [RFC5286] provides specification for
IP Fast Reroute with Loop-Free Alternates (LFA).
R
... ...
| |
+-----+ +-----+
| U' | | U |
+-+---+ +-----+
| |
| 5 4 | |
| | | \|/
\|/ | |
| +-----+ |
+----| Z |---+
+--+--+
|
|
| 10
|
+----------+----------+
| |
+--+--+ +--+--+
|Leaf | | Leaf|
+-----+ +-----+
Figure 2.
In the absence of ECMP paths from Z towards root node R, IGPs may
compute LFA paths from Z towards the root node. Z would select LDP
peer on primary next-hop provided by IGP as primary upstream LSR U
and peers on LFA next-hops as candidate backup upstream LSRs U'.
Rapid upstream failure protection is achieved through use of pre-
calculated backup next-hops that are loop-free and safe to use until
the distributed network convergence process completes. This simple
approach does not require any support from other routers. The extent
to which this goal can be met by this specification is dependent on
Dutta, et al. Expires January 4, 2012 [Page 6]
Internet-Draft mLdp Upstream Redundancy July 2011
the LFA topology of the network. Especially when networks does not
have ECMP, then backup stream LSR selection using LFA has significant
advantages. It is RECOMMENDED that LFA next-hops computed for this
purpose are "Node-Protecting", that is the backup LSR U' in turn must
not choose U as its primary upstream LSR. However without node
protection although upsteam node failure may not be protected, it
definitely provides link protection on failure of downstream link
from U to Z.
6. Fast Failover to Backup Upstream LSR
When node Z selects a backup upstream LSR and sends backup label
mapping L' for joining the mLdp tunnel path towards the root, it is
RECOMMENDED that Z installs L' into data plane with one exception :
L' MUST NOT be forwarding traffic to its downstream - it is kept in
"blocking mode". When Z detects failure on its primary upstream U, it
triggers switchover of traffic from primary upstream label L to L',
thus blocking L and unblocking L' in forwarding traffic to
downstream(s). This is important to avoid duplication of traffic to
downstream during failover. A single failover trigger may be
sufficient for fast switchover of traffic in all mLdp tunnels that
have selected U as primary upstream to their respective backup
upstream labels.
For some implementations it may not be possible to pre-install a
backup label L' into data plane in blocking mode. On primary upstream
failure, if L' is added before L is removed, there is a potential
risk of packet duplication, and/or the creation of transient data
plane forwarding loop. If L is removed before L' is added, packet
loss may result. For such implementations the RECOMMENDED procedure
is to remove L before adding L'.
7. Security Considerations
This document does not require additional security considerations to
what is required in [MLDP].
8. IANA Considerations
There is no IANA considerations required by this document.
Dutta, et al. Expires January 4, 2012 [Page 7]
Internet-Draft mLdp Upstream Redundancy July 2011
9. References
9.1. Normative References
[MLDP] Ina Minei, Kireeti Kompella, IJsbrand Wijnands, Bob Thomas,
"Label Distribution Protocol Extensions for Point-to-
Multipoint and Multipoint-to-Multipoint Label Switched
Paths", draft-ietf-mpls-ldp-p2mp-11.txt, October 2010
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5286] A. Atlas, A. Zinin, "Basic Specification for IP Fast
Re Route: Loop-Free Alternates.
9.2. Informative References
TBD.
10. Acknowledgments
Authors would like to acknowledge reviews and valuable feedbacks from
Paul Kwok.
This document was prepared using 2-Word-v2.0.template.dot.
Dutta, et al. Expires January 4, 2012 [Page 8]
Internet-Draft mLdp Upstream Redundancy July 2011
Authors' Addresses
Pranjal Kumar Dutta
Alcatel-Lucent
701, E Middlefield Road,
Mountain View, CA 94043,
USA.
Email: pranjal.dutta@alcatel-lucent.com
Wim Henderickx
Alcatel-Lucent
Copernicuslaan 50
2018 Antwerp, Belgium
Email: wim.henderickx@alcatel-lucent.be
Dutta, et al. Expires January 4, 2012 [Page 9]