Internet Engineering Task Force D. Ceccarelli Internet-Draft D. Caviglia Intended status: Informational F. Fondelli Expires: August 2, 2009 Ericsson M. Corsi Altran A. D'Alessandro A. Di Giglio Telecom Italia January 29, 2009 P2MP traffic protection in MPLS-TP ring topology draft-ceccarelli-mpls-tp-p2mp-ring-00 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 August 2, 2009. 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 (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. Ceccarelli, et al. Expires August 2, 2009 [Page 1] Internet-Draft draft-ceccarelli-mpls-tp-p2mp-ring-00 January 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 . . . . . . . . . . . . . 16 6.4. Multiple Failures Comparison . . . . . . . . . . . . . . . 17 7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 17 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 10. Security Considerations . . . . . . . . . . . . . . . . . . . 18 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 11.1. Normative References . . . . . . . . . . . . . . . . . . . 18 11.2. Informational References . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Ceccarelli, et al. Expires August 2, 2009 [Page 2] Internet-Draft draft-ceccarelli-mpls-tp-p2mp-ring-00 January 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 August 2, 2009 [Page 3] Internet-Draft draft-ceccarelli-mpls-tp-p2mp-ring-00 January 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 August 2, 2009 [Page 4] Internet-Draft draft-ceccarelli-mpls-tp-p2mp-ring-00 January 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 August 2, 2009 [Page 5] Internet-Draft draft-ceccarelli-mpls-tp-p2mp-ring-00 January 2009 Source | +---+ | | +---+ / \ / \ / \ +---+ +---+ | | | | +---+ +---+ | | | | Metro Core Ring | | +---+ +---+ | | | |-->DSLAM1 +---+ +---+ \ / \ / \ / +---+ | | +---+ / \ / \ / \ +---+ +---+ | | | |-->DSLAM2 +---+ +---+ \ / \ / Metro Access Ring \ / +---+ | | +---+ | V DSLAM3 Single node ring interconnection Figure 2 Ceccarelli, et al. Expires August 2, 2009 [Page 6] Internet-Draft draft-ceccarelli-mpls-tp-p2mp-ring-00 January 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 frame replication and frames 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 August 2, 2009 [Page 7] Internet-Draft draft-ceccarelli-mpls-tp-p2mp-ring-00 January 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 4461] and P2MP PWE3s [DRAFT-PWE3-P2MP]. The use of a P2MP LSP instead of many P2P LSPs avoids traffic replication by the ingress node and a waste of bandwidth 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 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 August 2, 2009 [Page 8] Internet-Draft draft-ceccarelli-mpls-tp-p2mp-ring-00 January 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 August 2, 2009 [Page 9] Internet-Draft draft-ceccarelli-mpls-tp-p2mp-ring-00 January 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 August 2, 2009 [Page 10] Internet-Draft draft-ceccarelli-mpls-tp-p2mp-ring-00 January 2009 Protected LSP: A->B->[C]->[D]->E->[F] --- LINK FAILURE --- 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 FAILURE --- 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 failure 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 August 2, 2009 [Page 11] Internet-Draft draft-ceccarelli-mpls-tp-p2mp-ring-00 January 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 Failure 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 August 2, 2009 [Page 12] Internet-Draft draft-ceccarelli-mpls-tp-p2mp-ring-00 January 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, but the recovery mechanism assumes that node C is failed, so the backup path is routed towards node D (merge point) even if node C, which is up and working, does not received the traffic flow. 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 Failure Configuration Figure 7 Ceccarelli, et al. Expires August 2, 2009 [Page 13] Internet-Draft draft-ceccarelli-mpls-tp-p2mp-ring-00 January 2009 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. 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 FAILURE --- 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] 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 August 2, 2009 [Page 14] Internet-Draft draft-ceccarelli-mpls-tp-p2mp-ring-00 January 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 August 2, 2009 [Page 15] Internet-Draft draft-ceccarelli-mpls-tp-p2mp-ring-00 January 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 failure or node failure. 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 2816] 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 August 2, 2009 [Page 16] Internet-Draft draft-ceccarelli-mpls-tp-p2mp-ring-00 January 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 August 2, 2009 [Page 17] Internet-Draft draft-ceccarelli-mpls-tp-p2mp-ring-00 January 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 [RFC4461] Yasukawa, S., "Signaling Requirements for Point-to- Multipoint Traffic-Engineered MPLS Label Switched Paths (LSPs)", RFC 4461, April 2006. [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. [RFC2816] Ghanwani, A., Pace, J., Srinivasan, V., Smith, A., and M. Seaman, "A Framework for Integrated Services Over Shared and Switched IEEE 802 LAN Technologies", RFC 2816, May 2000. Ceccarelli, et al. Expires August 2, 2009 [Page 18] Internet-Draft draft-ceccarelli-mpls-tp-p2mp-ring-00 January 2009 [RFC4427] Mannie, E. and D. Papadimitriou, "Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4427, March 2006. [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] Jounay, F., "Requirements for Point-to-Multipoint Pseudowire", 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 Diego Caviglia Ericsson Via A. Negrone 1/A Genova - Sestri Ponente Italy Email: diego.caviglia@ericsson.com Ceccarelli, et al. Expires August 2, 2009 [Page 19] Internet-Draft draft-ceccarelli-mpls-tp-p2mp-ring-00 January 2009 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 Andrea Di Giglio Telecom Italia Via G. Reiss Romoli, 274 Torino Italy Email: andrea.digiglio@telecomitalia.it Ceccarelli, et al. Expires August 2, 2009 [Page 20]