IETF A. Rhodes Internet-Draft N. Neate Intended status: Informational D. McWalter, Ed. Expires: September 5, 2009 Data Connection Ltd March 4, 2009 Problems observed with RSVP recovery signaling draft-rhodes-rsvp-recovery-signaling-01.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 September 5, 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. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this Rhodes, et al. Expires September 5, 2009 [Page 1] Internet-Draft RSVP recovery signaling March 2009 material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Abstract Implementation experience with RSVP-TE recovery signaling has uncovered some problems. Associations between LSPs in different sessions are forbidden. Protecting LSPs cannot themselves be protected. Overlapping repairs cause loss of traffic. This draft provides details of these problems for the community to consider. Rhodes, et al. Expires September 5, 2009 [Page 2] Internet-Draft RSVP recovery signaling March 2009 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Association between LSPs in different sessions . . . . . . 4 3.2. LSP association in multi-domain protection cases . . . . . 4 3.3. Protecting LSPs cannot themselves be protected . . . . . . 4 3.4. Overlapping repairs cause loss of traffic . . . . . . . . 5 3.5. segment-recording-desired flag is unassigned . . . . . . . 5 4. Detail . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Association between LSPs in different sessions . . . . . . 5 4.2. LSP association in multi-domain protection cases . . . . . 7 4.3. Protecting LSPs cannot themselves be protected . . . . . . 8 4.4. Overlapping repairs cause loss of traffic . . . . . . . . 8 4.5. segment-recording-desired flag is unassigned . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. Revision History . . . . . . . . . . . . . . . . . . . . . . . 10 7.1. Changes in -01 . . . . . . . . . . . . . . . . . . . . . . 10 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 9. Informative References . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Rhodes, et al. Expires September 5, 2009 [Page 3] Internet-Draft RSVP recovery signaling March 2009 1. Introduction This draft describes problems. It does not propose solutions. Our purpose in writing this draft is to determine how to resolve some RSVP-TE recovery problems we have encountered. We believe these problems are due to limitations in existing RSVP signaling procedures. We would like the community to consider whether the following scenarios are within the requirements for RSVP-TE protection. If so, we would like comments on whether we have correctly interpreted the existing RSVP-TE signaling proceduress in each case. If so, we solicit further collaboration in preparing proposals for interoperable solutions. 2. Terminology GMPLS recovery terminology is introduced by [RFC4427]. 'End-to-end protection' (e2e) procedures are defined by [RFC4872]. 'Segment recovery' procedures are defined by [RFC4873]. 3. Summary 3.1. Association between LSPs in different sessions Segment recovery protecting LSPs may have a different endpoint address from the corresponding protected LSP. The protected and protecting LSPs are therefore in different Sessions. The Association object of type 1 (recovery) is not effective in this case, as the Association ID can only associate to an LSP ID within the same Session. 3.2. LSP association in multi-domain protection cases End-to-end protected LSPs may pass through several addressing domains, resulting in mappings of addresses in the Session and Sender-Template. This causes difficulties for LSP endpoints attempting to associate protecting and protected LSPs. 3.3. Protecting LSPs cannot themselves be protected End-to-end or segment protection can be applied to a protecting LSP. That LSP is both protecting and protected. This cannot be signaled Rhodes, et al. Expires September 5, 2009 [Page 4] Internet-Draft RSVP recovery signaling March 2009 because only a single Protection object is allowed and it contains a single bit to indicate whether the LSP is protecting or protected. 3.4. Overlapping repairs cause loss of traffic Segment protection can be provided by two overlapping recovery paths. A single failure may trigger restoration using both repairs. Traffic is lost in this case. 3.5. segment-recording-desired flag is unassigned [RFC4873] s5.2 defines this flag, but no value is given. We need to ask IANA to assign a value. 4. Detail 4.1. Association between LSPs in different sessions End-to-end recovery uses Association objects of type 1 (recovery) to associate LSPs belonging to the same session. Association ID is (in most cases) set to the LSP ID of the associated LSP. See [RFC4872] s4.3, s6.1 and s16. [RFC4873] s3.2 and s3.2.1 state that procedures for use of the Association ID in segment recovery are not modified from those defined in [RFC4872] for end-to-end recovery. The following example shows that different procedures are necessary. A G D \ / \ / \ / \ / B-----C / \ / \ E F Protected LSP1: A-B-C-D, LSP ID 5 Protected LSP2: E-B-C-F, LSP ID 5 Segment recovery LSP1: B-G-C (1+1 protection) Segment recovery LSP2: B-G-C (1+1 protection) It is not possible for B and C to use LSP ID 5 to associate the two segment recovery LSPs with the protected LSPs. Discussion with authors suggests that it is intended that B assigns an arbitrary value as the Association ID, although this is not clearly spelled out. Here is how this applies to the example: Rhodes, et al. Expires September 5, 2009 [Page 5] Internet-Draft RSVP recovery signaling March 2009 Protected LSP1: A-B-C-D, LSP ID 5, Assoc ID 23 Protected LSP2: E-B-C-F, LSP ID 5, Assoc ID 24 Segment recovery LSP1: B-G-C (1+1 protection) Assoc ID 23 Segment recovery LSP2: B-G-C (1+1 protection) Assoc ID 24 This works in many cases, but introduces ambiguity when both segment recovery and end-to-end recovery are used in a network. ?? protected LSP3: B-C, LSP ID 1, Assoc ID 25 Segment recovery LSP: B-G-C (1+1 protection) LSP ID 2, Assoc ID 25 End-to-end recovery LSP: B-G-C (1+1 protection) LSP ID 25, Assoc ID 1 It is not possible to decide which of these recovery LSPs protects LSP3, at least not using existing procedures. The difficulty becomes more marked as additional LSPs are added: ?? protected LSP3: B-C, LSP ID 1, Assoc ID 25 Segment protected LSP4: A-B-C-D, LSP ID 5, Assoc ID 1 ?? recovery LSP5: B-G-C (1+1 protection) LSP ID 2, Assoc ID 25 ?? recovery LSP6: B-G-C (1+1 protection) LSP ID 25, Assoc ID 1 (All Association objects are Type 1, Association Source B). Significant analysis is required to determine which LSPs might be associated, and which recovery LSPs are segment or end-to-end recovery. In this case, we might choose to regard LSP3 as segment protected by LSP5 rather than e2e protected by LSP6, as this allows us to associate LSP4 with LSP6. Such deductions may fail or prove incorrect where protected and recovery LSPs are not 1:1 paired. Therefore we can expect to see transient mapping errors as LSPs are established and released. We can also expect to see permanent errors for recovery schemes such as (Full) LSP rerouting that do not always pair protected and recovery LSPs. Two approaches to remove this difficulty have been suggested. Both modify [RFC4873] procedures. 1. For a given Association Source, match Association objects by first looking for a matching segment recovery Association ID. If none exists, then match by treating Association ID as an LSP ID within the given Session. This resolves the ambiguity but restricts identifier use at the Association Source: values chosen as segment recovery Association IDs are unusable as LSP IDs from that source, and vice versa. A branch node implementing this approach would not allow management to use the full range of LSP IDs. Rhodes, et al. Expires September 5, 2009 [Page 6] Internet-Draft RSVP recovery signaling March 2009 2. Introduce a new Association type for segment recovery. Use Association type 1 only for end-to-end recovery. This removes the ambiguity. This keeps separate the LSP ID and Association ID number spaces. The meaning of the Association ID is given by the Association type. This is back-compatible with deployments of [RFC4872] but disrupts deployments of [RFC4873]. 4.2. LSP association in multi-domain protection cases A GMPLS domain may contain multiple IP addressing domains. Therefore an LSP may traverse multiple IP addressing domains. [RFC4927] and [RFC5376] show inter-area and inter-AS (G)MPLS-TE tunnel establishment. A given IP address may occur in more than one area or AS. (Otherwise the areas or ASes are not separate addressing domains). In order to support this, address mappings must modify the Session and Sender- Template at address domain boundaries. Protected and protecting LSPs may achieve diversity by traversing different domains. The cumulative modifications to Session and Sender-Template may result in the LSPs being in different sessions at the merge point. ........ ........... ........ . . . . . . . A------B-----C------D . . / . . . . \ . . / . .....2..... . \ . . I 1 3 E . . \ . .....4..... . / . . \ . . . . / . . F------G-----H------J . . . . . . . ........ ........... ........ In this illustration, four addressing domains (1-4) are shown. Together they make up a GMPLS domain across which LSPs can be set up. If two LSPs take the paths IABCDE and IFGHJE, then it is unclear whether these LSPs can be considered to be in the same session at node E. A/B translates Tunnel Sender / ext tunnel ID from I to 'K'. C/D translates Tunnel Sender / ext tunnel ID from K to 'L'. F/G translates Tunnel Sender / ext tunnel ID from I to 'M'. H/J translates Tunnel Sender / ext tunnel ID from M to 'N'. So E may regard the LSPs as being in different sessions, as their Rhodes, et al. Expires September 5, 2009 [Page 7] Internet-Draft RSVP recovery signaling March 2009 extended tunnel ID will differ, as will their tunnel sender address and any Association Source. These values were all set to 'I' in addressing domain 1. In such cases, the statement of [RFC4872] s6.1 that "both LSPs MUST belong to the same session" is difficult to apply. End-to-end protection might therefore not be applicable to a GMPLS domain containing multiple IP addressing domains. Applicability might be achieved if the GMPLS address mapping peformed at IP addressing domain boundaries (AB, CD, FG, HJ) within a GMPLS domain were to be specified or constrained. This is for discussion. 4.3. Protecting LSPs cannot themselves be protected A segment recovery repair path can itself be protected by end-to-end or segment recovery repairs, according to [RFC4873] s2. The result is an LSP segment that is both protected and protecting. However, only one protection object may be signaled. See [RFC4872] s17 and [RFC4873] s7. The (P)rotecting bit in the protection object should be set for the LSP's protecting role, but clear for its protected role. See [RFC4872] s4.2.1, s14.1 and [RFC4873] s6.1. Therefore protecting LSPs cannot themselves be protected by repair paths (unless we include non-interoperable procedures). 4.4. Overlapping repairs cause loss of traffic Consider the following topology: K-----------L / \ A===B===C===D===E===F===G===H \ / I-----------J Primary bidirectional LSP A-B-C-D-E-F-G-H is protected by two overlapping segment recovery paths B-K-L-F and C-I-J-G. Suppose 1:1 protection with extra traffic. This 'overlapping protection' is a valid case, see [RFC4873] section 1. Consider a failure of link D-E. Rhodes, et al. Expires September 5, 2009 [Page 8] Internet-Draft RSVP recovery signaling March 2009 K-----------L / \ A===B===C===D=X=E===F===G===H \ / I-----------J D detects this locally, and sends Notify to C (first Notify object in the received Path). C and G communicate to remove extra traffic from the C-I-J-G repair, and then send and receive normal traffic on C-I and G-J. Meanwhile, E also detects the failure locally, and sends Notify to F (first Notify object in the received Resv). F likewise communicates with B and normal traffic is sent and received on B-K and F-L. K----->-----L / \ A->-Bx<-C---D-X-E---F->xG<--H \ / I-----<-----J Forward traffic reaches G on the link F-G. However, G has switched to send and receive on G-J. Reverse traffic reaches B on C-B. However, B has switched to send and receive on B-K. Thus the standard procedure causes the loss of traffic in both directions. It may possible to solve this problem by configuring or otherwise assigning master/slave roles to the branch and merge points. See [RFC4426] s2.3. Currently there is no protocol description for how the master/slave roles might be dynamically assigned, nor how configured master/slave roles would affect [RFC4872] or [RFC4873] switchover. The mandatory procedures from [RFC4872] s6.2 and s7.2 (applied to segment recovery by [RFC4873] s2.1) prescribe the behaviour of the endpoints. It may be that procedures need to be modified so that endpoints have some latitude to decide not to perform switchover in some cases. It is possible to detect the 'overlapping repairs' condition at nodes B and G by using SRRO objects. These are optionally present between F and H on the path, and between C and A on the Resv, see [RFC4873] s2 and s5.2. In order to detect the problem reliably, procedures would need to change to make them mandatory. Rhodes, et al. Expires September 5, 2009 [Page 9] Internet-Draft RSVP recovery signaling March 2009 4.5. segment-recording-desired flag is unassigned [RFC4873] s5.2 assigns this flag as part of the SESSION_ATTRIBUTE object. However, no request was made to IANA to assign a value for it. We could correct this omission by asking IANA to assign a value. At the time of writing 0x40 is the next available value, see http:// www.iana.org/assignments/rsvp-te-parameters/rsvp-te-parameters.txt Note that it is also open to specify that an LSP_ATTRIBUTE flag for this purpose. For discussion. 5. Security Considerations This document does not propose any protocol changes. 6. IANA Considerations None. 7. Revision History 7.1. Changes in -01 Sections 3.1 and 4.1 better describe interactions between end-to-end and segment recovery use of Association type 1 Association ID. Sections 3.5 and 4.5 added, describing a missing codepoint. Section 4.1 includes examples. Section 4.1 includes Added Adrian Farrel's suggestion for egress to match segment recovery associations in precedence to end-to-end recovery associations. Section 4.2 includes an example. Section 4.2 questions the applicability of [RFC4872] to GMPLS domains containing multiple IP addressing domains. Section 4.4 notes that the SRRO object could provide a tool for detecting overlapping repairs, though its presence is not mandatory. Section 4.4 is updated with discussion of [RFC4426] roles, which do Rhodes, et al. Expires September 5, 2009 [Page 10] Internet-Draft RSVP recovery signaling March 2009 not appear to provide a solution. 8. Acknowledgements The authors would like to thank all who have contributed to our understanding of these issues, particularly Snigdho Bardalai, Adrian Farrel, Remi Theillaud and Dimitri Papadimitriou. 9. Informative References [RFC4426] Lang, J., Rajagopalan, B., and D. Papadimitriou, "Generalized Multi-Protocol Label Switching (GMPLS) Recovery Functional Specification", RFC 4426, March 2006. [RFC4427] Mannie, E. and D. Papadimitriou, "Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4427, March 2006. [RFC4872] Lang, J., Rekhter, Y., and D. Papadimitriou, "RSVP-TE Extensions in Support of End-to-End Generalized Multi- Protocol Label Switching (GMPLS) Recovery", RFC 4872, May 2007. [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, "GMPLS Segment Recovery", RFC 4873, May 2007. [RFC4927] Le Roux, J., "Path Computation Element Communication Protocol (PCECP) Specific Requirements for Inter-Area MPLS and GMPLS Traffic Engineering", RFC 4927, June 2007. [RFC5376] Bitar, N., Zhang, R., and K. Kumaki, "Inter-AS Requirements for the Path Computation Element Communication Protocol (PCECP)", RFC 5376, November 2008. Authors' Addresses Andrew Rhodes Data Connection Ltd 100 Church Street Enfield EN2 6BQ United Kingdom Email: adr@dataconnection.com Rhodes, et al. Expires September 5, 2009 [Page 11] Internet-Draft RSVP recovery signaling March 2009 Nic Neate Data Connection Ltd 100 Church Street Enfield EN2 6BQ United Kingdom Email: nhn@dataconnection.com David McWalter (editor) Data Connection Ltd 100 Church Street Enfield EN2 6BQ United Kingdom Email: dmcw@dataconnection.com Rhodes, et al. Expires September 5, 2009 [Page 12]