Internet Engineering Task Force D. Ceccarelli
Internet-Draft D. Caviglia
Intended status: Informational F. Fondelli
Expires: February 19, 2010 Ericsson
M. Corsi
Altran
A. D'Alessandro
Telecom Italia
August 18, 2009
P2MP traffic protection in MPLS-TP ring topology
draft-ceccarelli-mpls-tp-p2mp-ring-01
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 February 19, 2010.
Copyright Notice
Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Ceccarelli, et al. Expires February 19, 2010 [Page 1]
Internet-Draft draft-ceccarelli-mpls-tp-p2mp-ring-01 August 2009
Abstract
Purpose of this ID is to describe requirements and possible solutions
for point to multipoint (P2MP) traffic distribution over
interconnected MPLS-TP rings. The rationale for an ID on such a
specific application is illustrated in the rest of the document.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Scope of this document . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . 4
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Topology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Bandwidth Optimization . . . . . . . . . . . . . . . . . . 7
4.3. Backup LSP Optimization . . . . . . . . . . . . . . . . . 7
4.4. Protection switching time . . . . . . . . . . . . . . . . 7
4.5. Revertiveness . . . . . . . . . . . . . . . . . . . . . . 8
4.6. Frequent protection switching prevention . . . . . . . . . 8
4.7. Manual commands . . . . . . . . . . . . . . . . . . . . . 8
4.8. Protection Mechanisms . . . . . . . . . . . . . . . . . . 8
5. Possible solutions for P2MP traffic distribution . . . . . . . 8
6. Proposed recovery methods . . . . . . . . . . . . . . . . . . 8
6.1. Fast Rerouting (FRR) . . . . . . . . . . . . . . . . . . . 9
6.1.1. Fast Rerouting-Transport Profile (FRR-TP) . . . . . . 9
6.2. Optimized Multicast Fast Rerouting (ROM-FRR) . . . . . . . 14
6.3. Bandwidth Utilization Comparison . . . . . . . . . . . . . 17
6.4. Multiple Failures Comparison . . . . . . . . . . . . . . . 18
7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 18
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
10. Security Considerations . . . . . . . . . . . . . . . . . . . 19
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
11.1. Normative References . . . . . . . . . . . . . . . . . . . 19
11.2. Informational References . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
Ceccarelli, et al. Expires February 19, 2010 [Page 2]
Internet-Draft draft-ceccarelli-mpls-tp-p2mp-ring-01 August 2009
1. Introduction
1.1. Background
MPLS-TP is a joint ITU-T/IETF effort to include an MPLS Transport
Profile within the IETF MPLS architecture to support the capabilities
and functionalities of a packet transport network as defined by
ITU-T. In the MPLS-TP requirements draft [DRAFT-JENKIS] it is
highlighted that an MPLS-TP architecture must allow a smooth
migration from legacy networks (e.g. SONET/SDH) to packet transport
networks and support, in a reliable way, the accelerating growth of
packet-based services (such as VoIP, L2/L3 VPN, IPTV, RAN
backhauling, etc.). That migration must be accomplished preserving
carriers investments in both Capital Expenditure (CAPEX) and
Operational Expense (OPEX) as much as possible. Most of today
deployed SDH/SONET networks (some hundreds of thousands) all over the
world are based on ring topology, this assumption being especially
true for Metro-Core and Metro-Access networks.
Metro Area ring based networks are usually composed by a main Metro-
Core ring and several minor Metro-Access rings. The interconnection
between such rings is mainly based on a single node or on a couple of
nodes (one or more hop away from the first one).
Therefore, it is desirable that MPLS-TP solution was based on
interconnected ring architectures that were previously used by SONET/
SDH in order to avoid needs of digging new fibers (very expensive
especially in Europe), or lease dark fibers, in metro areas and
maintain low cost. If we combine the previous topology
considerations with the fact that the most interesting applications
leading the network transformation are P2MP applications (e.g.
IPTV), we reach the point that MPLS-TP must support an efficient
solution for P2MP applications over interconnected rings. It is also
important to note that those high value applications need appropriate
resiliency, at least single node/link failure recovery.
The solutions proposed in this document are data plane driven and are
thought to be able to work in absence of control plane. Nevertheless
a ring network allows the set up of bandwidth optimizing control
plane driven solutions. Such solutions are out of the scope of this
document and will be discussed in further IDs.
1.2. Scope of this document
This document provides both functional requirements and a network
solution for MPLS-TP ring based topology networks that support
reliable point-to-multipoint services.
Ceccarelli, et al. Expires February 19, 2010 [Page 3]
Internet-Draft draft-ceccarelli-mpls-tp-p2mp-ring-01 August 2009
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. Problem Statement
This document addresses the bandwidth usage optimization of reliable
p2mp traffic distribution (e.g. IPTV) over MPLS-TP networks based on
interconnected ring topology (physical or logical). Resiliency must
be based on recovery mechanisms able to restore traffic in about
50ms, without usage of any control plane accordingly with the MPLS-TP
general requirements [DRAFT-JENKINS] the recovery mechanism should
not rely on any control plane. Control plane has to be intended in
the sense of signaling and/or routing protocols, namely the GMPLS
Control Plane suite.
The following picture illustrates a typical interconnected ring
topology that can be found in metro networks; of course real
topologies involve a huger amount of rings and nodes.
The source node can be considered as a video server that distributes
a p2mp video stream towards different DSLAMs. The usage of redundant
video servers located in different nodes is allowed. Reliable
bandwidth optimization is for further study.
DSLAM1 is directly connected to the MetroCore ring while DSLAM2 and
DSLAM3 are connected to the Metro Access ring.
Ceccarelli, et al. Expires February 19, 2010 [Page 4]
Internet-Draft draft-ceccarelli-mpls-tp-p2mp-ring-01 August 2009
Source
|
+---+ +---+
| |------------| |-->DSLAM1
+---+ +---+
| |
| Metro Core |
| Ring |
| |
+---+ +---+
| |------------| |
+---+ +---+
/\
/ \
/ \ Metro Access Ring
+---+ +---+
| |------| |
+---+ +---+
| |
V V
DSLAM2 DSLAM3
Interconnected ring topology
Figure 1
4. Requirements
This paragraph lists and explains the main requirements to be
satisfied by a network in order to provide a reliable MPLS-TP based
infrastructure for P2MP traffic transport. P2MP traffic transport
over an MPLS-TP network requirements are based on [DRAFT-JENKINS],
[DRAFT-BLB] and [DRAFT-SPRECHER].
4.1. Topology
The network topology is made of one main ring (e.g. Metro Core Ring)
and more minor rings (e.g. Metro Access Ring), if any.
The interconnection between two rings can consist of one single node
or a couple of nodes (the two nodes can be one or more hops away).
The two configurations originate two different kinds of topology. We
will call those topologies "Single node ring interconnection" and
"Dual node ring interconnection" respectively.
Ceccarelli, et al. Expires February 19, 2010 [Page 5]
Internet-Draft draft-ceccarelli-mpls-tp-p2mp-ring-01 August 2009
Source
|
+---+
| |
+---+
/ \
/ \
/ \
+---+ +---+
| | | |
+---+ +---+
| |
| | Metro Core Ring
| |
+---+ +---+
| | | |-->DSLAM1
+---+ +---+
\ /
\ /
\ /
+---+
| |
+---+
/ \
/ \
/ \
+---+ +---+
| | | |-->DSLAM2
+---+ +---+
\ /
\ / Metro Access Ring
\ /
+---+
| |
+---+
|
V
DSLAM3
Single node ring interconnection
Figure 2
Ceccarelli, et al. Expires February 19, 2010 [Page 6]
Internet-Draft draft-ceccarelli-mpls-tp-p2mp-ring-01 August 2009
Source
|
+---+ +---+
| |------------| |-->DSLAM1
+---+ +---+
| |
| |
| METRO CORE |
+---+ RING +---+
| | | |
+---+ +---+
| |
| |
| |
+---+ +---+
| |------------| |
+---+ +---+
| |
| METRO ACCESS |
| RING |
| |
+---+ +---+
| |------------| |
+---+ +---+
| |
V V
DSLAM2 DSLAM3
Dual node ring interconnection
Figure 3
4.2. Bandwidth Optimization
Each node MUST minimize packet replication and packets SHOULD not be
replicated on the same unidirectional physical path.
4.3. Backup LSP Optimization
Optimization criteria and algorithms applied to the working LSP
SHOULD be respected/applicable also to the backup LSPs when the
protection is activated.
4.4. Protection switching time
The protection of the P2MP traffic over the interconnected rings MUST
provide a switching time within 50 ms. This means that the P2MP
traffic must be recovered, in case of either link or node failure,
Ceccarelli, et al. Expires February 19, 2010 [Page 7]
Internet-Draft draft-ceccarelli-mpls-tp-p2mp-ring-01 August 2009
within 50ms from the fault detection.
4.5. Revertiveness
It MUST be possible to configure the protection switching in
revertive or non revertive mode [DRAFT-BLB].
4.6. Frequent protection switching prevention
It MUST be possible to prevent frequent protection switching (i.e.
Hold off and Wait To Restore timers). [DRAFT-JENKINS]
4.7. Manual commands
Manual commands MUST be supported. [DRAFT-JENKINS]
4.8. Protection Mechanisms
A set of resilience mechanisms MUST be available. These mechanisms
MUST NOT rely on the control plane.
Protection mechanisms and control plane based resilient mechanisms
MUST coexist. [DRAFT-JENKINS]
5. Possible solutions for P2MP traffic distribution
The solutions proposed for the distribution of P2MP traffic over
interconnected ring networks (single node ring interconnection or
dual node ring interconnection), are based on P2MP LSPs [RFC
3031][RFC4875] and P2MP PWE3s [DRAFT-PWE3-P2MP].
The use of a P2MP LSP instead of many P2P LSPs reduces traffic
replication and bandwidth utilization in the network. However, the
solution for P2MP LSP described in [RFC4875] must be enhanced in
order to fully meet MPLS-TP P2MP ring distribution requirements.
P2MP LSPs MUST be provisioned via management plane
[RFC3812][RFC3813][P2MP-TE-MIB] without control plane support and
they MUST provide protection switching mechanisms relying on MPLS-TP
OAM in order to grant network survivability.
6. Proposed recovery methods
In this section two different recovery schemes based on the Fast
Rerouting (FRR) technique are analyzed and compared. The first
scheme is called FRR-TP (Fast Rerouting - Transport Profile) because
it is mainly based on the rerouting of the failed portion of the
Ceccarelli, et al. Expires February 19, 2010 [Page 8]
Internet-Draft draft-ceccarelli-mpls-tp-p2mp-ring-01 August 2009
network through a pre-provisioned path and exploits OAM
functionalities. The second one is called ROM-FRR (Ring Optimized
Multicast - Fast ReRouting) due to the fact that, despite being
applicable to any kind of network, it is optimized for the
distribution of multicast traffic over ring networks. The two
different recovery schemes will be compared and pros and cons of each
one will be highlighted.
6.1. Fast Rerouting (FRR)
[RFC4875] describes procedures to perform Fast Rerouting operations
for P2MP LSPs using extensions defined in [RFC4090].
The FRR mechanism is based on the re-direction of traffic flows on
backup LSPs as soon as a failure is detected. This switch is
extremely fast due to the fact that the backup LSPs are computed and
provisioned before the failure detection and the traffic is re-
directed as close to the failure point as possible. It is possible
to reach switching times of tens of milliseconds because no path
computation and set-up are performed and the failure notification
must not be propagated to the ingress LER.
In [RFC4090] two different methods are defined: one-to-one and
facility backup. The first method foreseen the creation of a detour
LSP for each protected LSP at each potential point of local repair,
while the second one creates a bypass tunnel to protect a set of LSPs
with similar backup constraints.
Both these methods are based on the assumption that each LSR of the
protected LSP is a Merge Point (MP), that is, it must be able to
rejoin the backup LSP to the protected one downstream of the
potential failure.
6.1.1. Fast Rerouting-Transport Profile (FRR-TP)
Both one-to-one and facility backup can be used as recovery
mechanisms for P2MP LSPs in MPLS-TP interconnected ring topology
networks but they need to be extended in order to fully meet MPLS-TP
protection requirements. This solution will be called FRR-TP.
MPLS-TP OAM SHOULD be used on each MPLS section to perform Continuity
Check (CC) operations. When a defect is detected, a hold-off timer
(with period configurable from 1 to 10s in steps of 100ms) SHOLUD be
started in order to prevent frequent protection switches. When the
timer expires and a defect condition is still present, the protection
switching SHOULD be initiated.
Externally initiated commands MAY be provided for manual control of
Ceccarelli, et al. Expires February 19, 2010 [Page 9]
Internet-Draft draft-ceccarelli-mpls-tp-p2mp-ring-01 August 2009
protection switching on each PLR. The following externally initiated
commands SHOULD be supported: Clear, Lockout of Protection, Forced
Switch, Manual Switch, Exercise.
In the following picture an example of FRR-TP application to a ring
topology is depicted.
Source
|
+---+ +---+
DSLAM3<-| F |-------------| A |
+---+ +---+
/ \
/ \
/ \
+---+ +---+
| E | | B |
+---+ +---+
\ /
\ /
\ /
+---+ +---+
| D |-------------| C |-->DSLAM1
+---+ +---+
|
V
DSLAM2
FRR-TP application to ring topology
Figure 4
The source of a P2MP traffic flow is connected to node A and a P2MP
LSP is created with A as ingress node and C, D and F as egress nodes
in order to deliver traffic to the different DSLAMs. In the
following figure it is possible to see the list of the protected LSP
and all the possible backup LSPs in case of link failure and node
failure configuration. "X's Backup" is the backup path activated by
X as a consequence of a failure affecting node Y (downstream node
with respect to X) or link X-Y, and square brackets indicate nodes
delivering traffic to the DSLAMs.
Ceccarelli, et al. Expires February 19, 2010 [Page 10]
Internet-Draft draft-ceccarelli-mpls-tp-p2mp-ring-01 August 2009
Protected LSP: A->B->[C]->[D]->E->[F]
--- LINK PROTECTION ---
A's Backup: A->F->E->D->C->B
B's Backup: B->A->F->E->D->C
C's Backup: C->B->A->F->E->D
D's Backup: D->C->B->A->F->E
E's Backup: E->D->C->B->A->F
--- NODE PROTECTION ---
A's Backup: A->F->E->D->C
B's Backup: B->A->F->E->D
C's Backup: C->B->A->F->E
D's Backup: D->C->B->A->F
E's Backup: E->D->C->B->A
Protected and Backup LSPs
Figure 5
In case of failure, let's say on link B-C, and link protection
configuration, the protected LSP is locally rerouted by B to C using
the pre-computed and set-up LSP depicted in figure 5. Considering
that the network has a ring topology, the only other way of reaching
C is moving counterclockwise and establishing an alternative path
from B to C trough A, F, E, D and C. Once C has been reached, the
traffic is re-joined to the protected LSP and delivered down to D, E
and F.
This is the list of nodes crossed by the traffic flow in case of
failure on link BC:
Ceccarelli, et al. Expires February 19, 2010 [Page 11]
Internet-Draft draft-ceccarelli-mpls-tp-p2mp-ring-01 August 2009
A-B (*) B-A-F-E-D-C (@) C-D-E-F (#)
Segment "upstream" backup path Segment "downstream"
with respect to with respect to
the failure the failure
Source
F *
+---+ +*--+
DSLAM3<##|# | |* | A
|# @|@@@@@@@@@@@@@@@@@@|*@@|
+---+ +---+
# @ * @
# @ * @
# @ * @
# @ * @
+---+ +---+
E |# @| |@@@|B
|# @| | |
+---+ +---+
# @
# @
# @ XXXXX Failure
# @
+---+ +---+
D |# @|@@@@@@@@@@@@@@@@@@|# |##>DSLAM1
|###|##################|# |
+---+ +---+
# C
#
V
DSLAM2
FRR-TP application to ring topology - Link protection Configuration
Figure 6
This example shows that the utilization of the FRR-TP method in ring
topology networks is not optimized in terms of bandwidth utilization
and number of hops to be crossed. The traffic flows through the same
links more than once and, in this particular case, all link are used
twice. For further considerations concerning bandwidth utilization
please see related paragraph.
This recovery mechanism shows a quite big limit when providing node
protection. In such a case, even if a failure affects a link, the
protection assumes that the failure affects the downstream node and
Ceccarelli, et al. Expires February 19, 2010 [Page 12]
Internet-Draft draft-ceccarelli-mpls-tp-p2mp-ring-01 August 2009
the backup path is redirected to the following node.
It is possible to show this limit considering the previous example
where node protection is configured. A failure affects link BC, the
recovery mechanism assumes that node C is failed, B redirects traffic
towards node D (i.e. merge point) through the appropriate LSP (i.e
[B, A, F, E, D]), then node C is excluded even if it is perfectly
functioning and even if the network has enough resources to reach it.
Ceccarelli, et al. Expires February 19, 2010 [Page 13]
Internet-Draft draft-ceccarelli-mpls-tp-p2mp-ring-01 August 2009
A-B (*) B-A-F-E-D-C (@) C-D-E-F (#)
Segment "upstream" backup path Segment "downstream"
with respect to with respect to
the failure the failure
Source
F *
+---+ +*--+
DSLAM3<##|# | |* | A
|# @|@@@@@@@@@@@@@@@@@@|*@@|
+---+ +---+
# @ * @
# @ * @
# @ * @
# @ * @
+---+ +---+
E |# @| |@@@|B
|# @| | |
+---+ +---+
# @
# @
# @ XXXXX Failure
# @
+---+ +---+
D |# @| | |-->!DSLAM1!
|###|------------------| |
+---+ +---+
# C
#
V
DSLAM2
FRR-TP application to ring topology - Node protection Configuration
Figure 7
6.2. Optimized Multicast Fast Rerouting (ROM-FRR)
ROM-FRR is a P2MP recovery mechanism based on FRR. It behaves in the
same manner as FRR-TP with the difference that it does not provide a
backup path between the end nodes of a failed link (link protection)
or between the upstream and downstream node of a failed node (node
protection), but a backup P2MP LSP from the upstream node with
respect to the failure and all the destinations downstream the
failure.
Ceccarelli, et al. Expires February 19, 2010 [Page 14]
Internet-Draft draft-ceccarelli-mpls-tp-p2mp-ring-01 August 2009
Considering the example depicted in figure 4 it is possible to
identify the protected LSP and all the possible backup LSPs. "X's
Backup" is the backup path activated by X as a consequence of a
failure affecting node Y (downstream node with respect to X) or link
X-Y, and square brackets indicate nodes delivering traffic to the
DSLAMs.
Protected LSP: A->B->[C]->[D]->E->[F]
--- LINK/NODE PROTECTION ---
A's Backup: A->[F]->E->[D]->[C]
B's Backup: B->A->[F]->E->[D]->[C]
C's Backup: C->B->A->[F]->E->[D]
D's Backup: D->C->B->A->[F]
E's Backup: E->D->C->B->A->[F]
Protected and Backup LSPs
Figure 8
ROM-FRR can be applied to any network topology but it is particularly
efficient for interconnected ring topologies.
In the following it is foreseen an example comparing the application
of the FRR-TP and ROM-FRR to the use case previously seen. The
topology is the same and the failure is considered to occur on link
BC. This is the list of nodes involved in the protection. This time
we highlight in brackets the nodes that drop and continue traffic
from the ring.
Ceccarelli, et al. Expires February 19, 2010 [Page 15]
Internet-Draft draft-ceccarelli-mpls-tp-p2mp-ring-01 August 2009
-- FRR-TP --
A-B B-A-F-E-D-C [C]-[D]-E-[F]
Segment "upstream" backup path Segment "downstream"
with respect to with respect to
the failure the failure
-- ROM-FRR --
A-B (*) B-A-[F]-E-[D]-[C] (@)
Segment "upstream" backup path
with respect to
the failure
Source
F *
+---+ +*--+
DSLAM3<@@|@ | |* | A
| @|@@@@@@@@@@@@@@@@@@|*@@|
+---+ +---+
@ * @
@ * @
@ * @
@ * @
+---+ +---+
E | @| |@@@|B
| @| | |
+---+ +---+
@
@
@ XXXXX Failure
@
+---+ +---+
D | @| | @@|@@>DSLAM1
| @|@@@@@@@@@@@@@@@@@@|@ |
+---+ +---+
@ C
@
V
DSLAM2
FRR-TP vs ROM-FRR
Ceccarelli, et al. Expires February 19, 2010 [Page 16]
Internet-Draft draft-ceccarelli-mpls-tp-p2mp-ring-01 August 2009
Figure 9
Comparing the two lists of nodes, it is possible to see that in this
particular case the number of hops crossed using FRR-TP is
significantly higher than the number of hops made by the traffic when
ROM-FRR is used (generally it is always higher or at least equal).
This implies a sensible waste of bandwidth on all those links that
are crossed in both directions.
Moreover FRR-TP is configured to face with a specific failure: link
protection or node protection. If the protection is configured to
react to a node failure but the failure affects a link, this results
in isolating node C so failing to feed DSLAM1.
This problem doesn't happen in case of ROM-FRR, because there is no
distinction between node protection and link protection. In case of
link BC or node C failure, the rerouting is performed in both cases
attempting to reach C. If the failure regards the link, the traffic
is correctly delivered to C, while if the failure affects node C, the
rerouting is correctly performed up to node D.
6.3. Bandwidth Utilization Comparison
Considering the ring network previously seen, it is possible to do
some bandwidth utilization considerations. The protected LSP is set
up from A to F clockwise and an X Mbps bandwidth is reserved along
the path. All the backup LSPs are preprovisioned counterclockwise,
each of them with reserved bandwidth X. These LSPs share the same
bandwidth in a SE (Shared Explicit) [RFC 2205] style.
The bandwidth reserved counterclockwise is not used when the
protected LSP is properly working and can be used for extra traffic
[RFC 4427].
In case of failure, the bandwidth actually used differs depending on
the recovery mechanism implemented. In case of FRR-TP, the bandwidth
used is X on both directions of almost each link, while in case of
ROM-FRR only the links from the ingress node to the node detecting
the failure have an X bandwidth used in both directions, while all
the others have an X bandwidth only in the counterclockwise
direction.
Let's suppose to have a failure on link B-C shown in figure 4. In
the following table it is possible to find the Bandwidth utilization
on each link (always equal to X), for each recovery mechanism and for
each direction (CW=clockwise, CCW=counterclockwise).
Ceccarelli, et al. Expires February 19, 2010 [Page 17]
Internet-Draft draft-ceccarelli-mpls-tp-p2mp-ring-01 August 2009
+----------------------------+----------------------------+
| FRR-TP | ROM-FRR |
+--------------+-------------+--------------+-------------+
| Link A-B | CW+CCW | Link A-B | CW+CCW |
| Link A-F | CCW | Link A-F | CCW |
| Link F-E | CW+CCW | Link F-E | CCW |
| Link E-D | CW+CCW | Link E-D | CCW |
| Link D-C | CW+CCW | Link D-C | CCW |
+--------------+-------------+--------------+-------------+
Bandwidth utilization comparison
Figure 10
6.4. Multiple Failures Comparison
A further comparison between FRR-TP and ROM-FRR can be done with
respect to their ability to react to multiple failures. FRR-TP
recovery mechanism hasn't the ability to recover from multiple
failures on a ring network, while ROM-FRR is able to recover, from
multiple failures.
Let's consider, for example, a double link failure affecting links
B-C and C-D shown in figure 4. The FRR-TP mechanism is not able to
recover from the failure because B, upon detecting the failure, has
no alternative paths to reach C. The whole P2MP traffic is lost.
ROM-FRR mechanism is able to partially recover from the failure, in
fact the backup P2MP LSP to node F and node D is correctly set up and
DSLAMs 2 and 3 continue receiving traffic.
7. Conclusions
The comparison of the FRR-TP an ROM-FRR methods leads to the
following assumptions:
1. ROM-FRR allows a sensible save of bandwidth. With respect to
figure 7 it is possible to see that only the links from the
ingress node to the failure (clockwise) are crossed in both ways
(A-B), while all the other ones (from the ingress to failure,
counterclockwise) are crossed just once(F-E-D-C).
2. The average number of hops crossed using FRR-TP is
significantly higher as a consequence of the previous bullet. In
the example shown in figure 7, the "farthest" node is reached in 9
hops using FRR-TP and only 6 hops using ROM-FRR. In general the
number of hops is always lower (or equal in the worst case) using
Ceccarelli, et al. Expires February 19, 2010 [Page 18]
Internet-Draft draft-ceccarelli-mpls-tp-p2mp-ring-01 August 2009
ROM-FRR.
3. FRR-TP must be configured in node protection or link
protection mode. This leads to a bug in case of link failure and
node protection configured, when the node supposed to be failed is
perfectly working but indeed isolated by the backup up.
4. FRR-TP is not able to react to multiple failures, while ROM-
FRR is able to partially recover from multiple failure, depending
on the resources affected.
8. Acknowledgements
TBD
9. IANA Considerations
This memo includes no request to IANA.
10. Security Considerations
This section will be added in a future version.
11. References
11.1. Normative References
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001.
[RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa,
"Extensions to Resource Reservation Protocol - Traffic
Engineering (RSVP-TE) for Point-to-Multipoint TE Label
Switched Paths (LSPs)", RFC 4875, May 2007.
[RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute
Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
May 2005.
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997.
[RFC4427] Mannie, E. and D. Papadimitriou, "Recovery (Protection and
Ceccarelli, et al. Expires February 19, 2010 [Page 19]
Internet-Draft draft-ceccarelli-mpls-tp-p2mp-ring-01 August 2009
Restoration) Terminology for Generalized Multi-Protocol
Label Switching (GMPLS)", RFC 4427, March 2006.
[RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau,
"Multiprotocol Label Switching (MPLS) Traffic Engineering
(TE) Management Information Base (MIB)", RFC 3812,
June 2004.
[RFC3813] Srinivasan, C., Viswanathan, A., and T. Nadeau,
"Multiprotocol Label Switching (MPLS) Label Switching
Router (LSR) Management Information Base (MIB)", RFC 3813,
June 2004.
[DRAFT-JENKINS]
Niven-Jenkins, B., "MPLS-TP Requirements", 2008.
[DRAFT-SPRECHER]
Sprecher, N., "MPLS-TP OAM Analysis", 2008.
[DRAFT-BLB]
Bocci, M., "A Framework for MPLS in Transport Networks",
2008.
[DRAFT-PWE3-P2MP]
Martini, L., "Signaling Root-Initiated Point-to-Multipoint
Pseudowires using LDP", 2008.
[DRAFT-P2MP-TE-MIB]
Farrel, A., "Point-to-Multipoint Multiprotocol Label
Switching (MPLS) Traffic Engineering (TE) Management
Information Base (MIB) module", 2008.
11.2. Informational References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Authors' Addresses
Daniele Ceccarelli
Ericsson
Via A. Negrone 1/A
Genova - Sestri Ponente
Italy
Email: daniele.ceccarelli@ericsson.com
Ceccarelli, et al. Expires February 19, 2010 [Page 20]
Internet-Draft draft-ceccarelli-mpls-tp-p2mp-ring-01 August 2009
Diego Caviglia
Ericsson
Via A. Negrone 1/A
Genova - Sestri Ponente
Italy
Email: diego.caviglia@ericsson.com
Francesco Fondelli
Ericsson
Via A. Negrone 1/A
Genova - Sestri Ponente
Italy
Email: francesco.fondelli@ericsson.com
Marco Corsi
Altran
Via A. Negrone 1/A
Genova - Sestri Ponente
Italy
Email: marco.corsi@altran.it
Alessandro D'Alessandro
Telecom Italia
Via G. Reiss Romoli, 274
Torino
Italy
Email: alessandro.dalessandro@telecomitalia.it
Ceccarelli, et al. Expires February 19, 2010 [Page 21]