IETF A. Rhodes Internet-Draft N. Neate Intended status: Informational D. McWalter, Ed. Expires: January 2, 2010 Data Connection Ltd July 1, 2009 MPLS-TP recovery control plane analysis draft-mcwalter-mpls-tp-recovery-cp-analysis-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. 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 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. 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 2, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. Rhodes, et al. Expires January 2, 2010 [Page 1] Internet-Draft RSVP recovery signaling July 2009 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. Abstract Segment recovery function can be signaled using the GMPLS Segment Recovery protocol, or by using LSP Hierarchy with End-to-End Recovery. This draft contrasts the two techniques, with particular attention to differences in control plane function and administrative options, and with regard to requirements for the MPLS-TP control plane. This draft discusses existing protocols. It proposes nothing new. Rhodes, et al. Expires January 2, 2010 [Page 2] Internet-Draft RSVP recovery signaling July 2009 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Draft status . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. GMPLS Segment Recovery . . . . . . . . . . . . . . . . . . . . 6 5.1. Description . . . . . . . . . . . . . . . . . . . . . . . 6 5.2. Function . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.3. Interaction with LSP Hierarchy . . . . . . . . . . . . . . 7 6. GMPLS Hierarchy with e2e Recovery . . . . . . . . . . . . . . 8 6.1. Description . . . . . . . . . . . . . . . . . . . . . . . 8 6.2. Function . . . . . . . . . . . . . . . . . . . . . . . . . 8 7. Comparison with MPLS-TP requirements and framework . . . . . . 9 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 10. Informative References . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Rhodes, et al. Expires January 2, 2010 [Page 3] Internet-Draft RSVP recovery signaling July 2009 1. Introduction MPLS-TP does not require the presence of a control plane. For networks where a control plane is present, the GMPLS control plane has been proposed, see [RFC5317]. One function of this control plane (among many) is the co-ordination of recovery actions, at various levels. Existing protocols should be used for this purpose if possible. See [I-D.ietf-mpls-tp-requirements] (3), (53) and (58). The most complex of the recovery functions co-ordinated by the control plane is segment recovery. End-to-end and span recovery could be treated as special cases of this (though they might not be). Therefore this document considers signaling of segment recovery as a starting point for analysis of the existing control plane for use in MPLS-TP. Existing GMPLS control plane signaling can achieve segment recovery function in two distinct ways. The data plane reality may be the same in both cases, but the function achieved differs, due to signaling details. It may be that the differences are important enough to justify the deployment of both signaling methods. We invite the community to comment. 2. Draft status This document is a work in progress. We may identify and contrast additional existing control plane methods that achieve segment recovery. We hope to improve our evaluation of these techniques under [I-D.ietf-mpls-tp-requirements] and [I-D.ietf-mpls-tp-survive-fwk]. 3. Terminology Terminology used in this document is consistent with [RFC4426] and [RFC4427]. GMPLS End-to-End Recovery and Segment Recovery are defined by [RFC4872] and [RFC4873]. LSP Hierarchy is described by [RFC4206], modified by Rhodes, et al. Expires January 2, 2010 [Page 4] Internet-Draft RSVP recovery signaling July 2009 [I-D.ietf-ccamp-lsp-hierarchy-bis]. 'Domain' is used loosely to indicate an IGP area or domain, MRN region, administrative domain, or an arbitrary administrative division. This is consistent with the definition in [I-D.helvoort-mpls-tp-rosetta-stone] and the 'Protection and Restoration Domains' defined in [I-D.ietf-mpls-tp-survive-fwk]. 'Nesting' in this document means 'strict containment' of domains, one within another. This is sometimes called 'Russian dolls' recursion. This usage is consistent with [I-D.ietf-mpls-tp-survive-fwk]. Note that [RFC4206] uses 'nesting' differently, to mean multiplexing of client LSPs onto a server tunnel using label stacking. 'e2e' and 'End-to-End' in this document takes the meaning from [RFC4872]. Note that [RFC5150] uses 'e2e' differently, an 'e2e LSP' being one that makes use of a virtual link provided by an S-LSP. 4. Summary The two existing segment recovery methods identified by this document are: - [RFC4873] GMPLS Segment Recovery - [RFC4872] GMPLS End-to-End Recovery of an H-LSP or S-LSP. Using [RFC4873] GMPLS Segment Recovery, signaling from the ingress node may specify the branch and merge points, and may specify the routes taken by both primary and protecting or restoration LSPs. The recovery scheme(s) must be specified by ingress, and are signaled all the way to egress. The branch point(s) have no choice of recovery scheme. It is possible to protect several successive segments using different schemes. Adding 'nested' levels of segment protection or recovery is not straightforward, either for the primary protected segment, or for segment protecting or restoration LSPs. This first method appears suited to networks where management function for the LSP is associated with the LSP ingress node, and where the protection or restoration function of intermediate domains is known at ingress, and recovery scheme(s) can be selected by ingress. A second method is GMPLS End-to-End Recovery of an H-LSP or S-LSP. This allows no control in signaling from the ingress node of the Rhodes, et al. Expires January 2, 2010 [Page 5] Internet-Draft RSVP recovery signaling July 2009 overlying LSP. Control is from the branch point, which is the ingress node for the H-LSP or S-LSP. The branch point selects the recovery scheme, and it is signaled only as far as the merge point, which is the egress node for the H-LSP or S-LSP. It is possible to protect several successive segments using different schemes. Adding several 'nested' levels of segment protection or restoration is straightforward, and can be applied either to the primary LSP or to the protection or restoration LSP, or to both. This second method appears suited to networks where management function is distributed between separate autonomous domains, which may include 'nested' domains. 5. GMPLS Segment Recovery 5.1. Description [A,B,C,D,E,F] is a working LSP. [RFC4873] GMPLS Segment Recovery allows [C,G,I,E] to be established as a protection or restoration LSP. A---B---C---D---E---F \ / G---I 5.2. Function LSP ingress (node A) must specify the protection or restoration scheme, and may specify the branch and merge points ('explicit control'), along with all or part of the primary path and protection or restoration paths. This information is signaled in the ERO and SERO. Ingress can be notified of the actual paths taken by the primary and protection or restoration paths, signaled in the RRO and SRRO. The branch point (node C) may dynamically identify itself ('dynamic control') and may choose the merge point (node E), and route between these points. But C cannot dynamically decide which protection scheme to use. More than one span of the LSP may be protected, using different protection or restoration schemes. This may be useful when an LSP crosses multiple autonomous domains or regions. It is difficult to add additional 'nested' protection for the segment Rhodes, et al. Expires January 2, 2010 [Page 6] Internet-Draft RSVP recovery signaling July 2009 [C,D,E] or for the LSP [C,G,I,E], assuming topology exists that would allow it. (This is because only one PROTECTION object can be signaled in a Path, see [RFC3473] s10.1 and [RFC4873] s4.2). 5.3. Interaction with LSP Hierarchy In the same topology, [RFC4206] and [I-D.ietf-ccamp-lsp-hierarchy-bis] allow H-LSPs or S-LSPs to be used between C and E. C and E may be region boundaries, or administrative domain boundaries, or the H-LSPs or S-LSPs may simply be provisioned at C. . . .Region . . or . .domain . . . A---B---C---D---E---F .\ /. . G---I . . . Then when [A,B,C,D,E,F] is set up as a working LSP, an H-LSP or S-LSP [C,D,E] is used (or triggered). And when [C,G,I,E] is established as a protection or restoration LSP, it too is used as an H-LSP or S-LSP. The status of [C,D,E] and [C,G,I,E] as H-LSPs or S-LSPs might have no effect on Segment Recovery signaling or function. Ingress control or dynamic control can be applied without change. If [C,D,E] and [C,G,I,E] are treated as private virtual links, then the ERO, SERO, RRO, SRRO and PPRO are unaffected. However, if these virtual links are advertised as Forwarding Adjacencies (FAs) C-E, then the ERO, SERO, RRO, SRRO and PPRO might use these virtual links instead. . . .Region . . or . .domain . . . A---B---C- - - -E---F .\ /. . - - . FA-LSPs C-E advertised as virtual topology Rhodes, et al. Expires January 2, 2010 [Page 7] Internet-Draft RSVP recovery signaling July 2009 6. GMPLS Hierarchy with e2e Recovery 6.1. Description There is a second way to achieve segment recovery function. End-to- End Recovery can be applied to the H-LSP or S-LSP [C,D,E]. The LSP [C,G,I,E] would then provide End-to-End protection or restoration for [C,D,E], rather than segment protection or restoration for [A,B,C,D,E,F]. . . .Region . . or . .domain . . . A---B---C- - - -E---F . . . . FA-LSP C-E advertised as virtual topology In this case, only one virtual link C-E might be advertised. This link could be advertised with an appropriate link protection type, depending on the protection or restoration scheme that is in use. 6.2. Function LSP ingress node A has no control via signaling. Node A can be aware of nothing other than the protection type advertised for the virtual link C-E. This may be a disadvantage or a benefit, depending on the nature of the network. Node C is free to choose any protection or restoration scheme, and may apply this autonomously within its domain. This is signaled only between the branch node and the merge node (C and E), which are ingress and egress nodes with respect to the H-LSP or S-LSP. More than one span of the LSP may be protected, using different protection or restoration schemes. This may be useful when an LSP crosses multiple autonomous domains or regions. Additional 'nested' protection for the segment [C,D,E] or for the LSP [C,G,I,E] can be added using further H-LSPs or S-LSPs. [A,B,C,D,E,F] could itself be used as an H-LSP or S-LSP. This may be useful when domains or regions are nested. Rhodes, et al. Expires January 2, 2010 [Page 8] Internet-Draft RSVP recovery signaling July 2009 7. Comparison with MPLS-TP requirements and framework [I-D.ietf-mpls-tp-requirements] 27 requires support for paths through multiple non-homogeneous domains. Both methods support control of recovery in this environment. [I-D.ietf-mpls-tp-requirements] 90B requires support for signaling of administrative control. This may refer to detailed administrative control of segment recovery from the ingress LSR. If so, this indicates a requirement for GMPLS Segment Recovery signaling. On the other hand, GMPLS Hierarchy with e2e Recovery appears better suited to the use of recovery at several levels simultaneously, as required by [I-D.ietf-mpls-tp-requirements] 58. It may also fit better with the concept of Protection and Recovery Domains introduced by [I-D.ietf-mpls-tp-survive-fwk] s4.5.3, especially in cases where these domains are nested. Comments on this comparison would be most welcome. 8. Security Considerations This document does not propose any protocol changes. 9. IANA Considerations None. 10. Informative References [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. [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. Rhodes, et al. Expires January 2, 2010 [Page 9] Internet-Draft RSVP recovery signaling July 2009 [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. [RFC5150] Ayyangar, A., Kompella, K., Vasseur, JP., and A. Farrel, "Label Switched Path Stitching with Generalized Multiprotocol Label Switching Traffic Engineering (GMPLS TE)", RFC 5150, February 2008. [RFC5317] Bryant, S. and L. Andersson, "Joint Working Team (JWT) Report on MPLS Architectural Considerations for a Transport Profile", RFC 5317, February 2009. [I-D.ietf-ccamp-lsp-hierarchy-bis] Shiomoto, K., Farrel, A., Rabbat, R., Ayyangar, A., and Z. Ali, "Procedures for Dynamically Signaled Hierarchical Label Switched Paths", draft-ietf-ccamp-lsp-hierarchy-bis-06 (work in progress), December 2008. [I-D.ietf-mpls-tp-requirements] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and S. Ueno, "MPLS-TP Requirements", draft-ietf-mpls-tp-requirements-09 (work in progress), June 2009. [I-D.ietf-mpls-tp-survive-fwk] Sprecher, N., Farrel, A., and H. Shah, "Multiprotocol Label Switching Transport Profile Survivability Framework", draft-ietf-mpls-tp-survive-fwk-00 (work in progress), April 2009. [I-D.helvoort-mpls-tp-rosetta-stone] Helvoort, H., Andersson, L., and N. Sprecher, "A Thesaurus for the Terminology used in Multiprotocol Label Switching Transport Profile (MPLS-TP) drafts/RFCs and ITU-T's Transport Network Recommendations.", draft-helvoort-mpls-tp-rosetta-stone-00 (work in progress), March 2009. Rhodes, et al. Expires January 2, 2010 [Page 10] Internet-Draft RSVP recovery signaling July 2009 Authors' Addresses Andrew Rhodes Data Connection Ltd 100 Church Street Enfield EN2 6BQ United Kingdom Email: adr@dataconnection.com 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 January 2, 2010 [Page 11]