MPLS Working Group Z. Ali, Ed. Internet-Draft Cisco Systems, Inc. Intended status: Standards Track N. Neate Expires: April 24, 2011 Metaswitch Networks October 25, 2010 Signaling RSVP-TE P2MP LSPs in an Inter-domain Environment draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp-05.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 April 24, 2011. Abstract Point-to-MultiPoint (P2MP) Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs) may be established using signaling techniques described in [RFC4875]. However, [RFC4875] does not address issues that arise when a P2MP-TE LSP is signaled in multi-domain networks. Specifically, it does not provide a mechanism to avoid re-merges in inter-domain P2MP TE LSPs. This document provides a framework and protocol extensions for establishing and controlling P2MP MPLS and GMPLS TE LSPs in multi-domain networks. This document borrows inter-domain TE terminology from [RFC4726], e.g., for the purposes of this document, a domain is considered to be any collection of network elements within a common sphere of address management or path computational responsibility. Examples of such domains include Interior Gateway Protocol (IGP) areas and Autonomous Systems (ASes). Ali & Neate Expires April 24, 2011 [Page 1] Internet-Draft RSVP-TE P2MP Inter-domain LSPs October 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Conventions used in this document . . . . . . . . . . . . . 4 2. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Signaling Options . . . . . . . . . . . . . . . . . . . . . 4 2.2. Path Computation Techniques . . . . . . . . . . . . . . . . 4 3. Signaling Procedures . . . . . . . . . . . . . . . . . . . . . 5 3.1. Crankback and Path Error . . . . . . . . . . . . . . . . . 5 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6.1. Normative References . . . . . . . . . . . . . . . . . . . 6 6.2. Informative References . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 Ali & Neate Expires April 24, 2011 [Page 2] Internet-Draft RSVP-TE P2MP Inter-domain LSPs October 2011 1. Introduction [RFC4875] describes how to set up point-to-multipoint (P2MP) Traffic Engineering Label Switched Paths (TE LSPs) for use in MultiProtocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. As with all other RSVP controlled LSPs, P2MP LSP state is managed using RSVP messages. While the use of RSVP messages is mostly similar to their P2P counterpart, P2MP LSP state differs from P2P LSP in a number of ways. In particular, the P2MP LSP must also handle the "re-merge" problem described in [RFC4875] section 18. The term "re-merge" refers to the situation when two S2L sub-LSPs branch at some point in the P2MP tree, and then intersect again at a another node further down the tree. This may occur due to discrepencies in the routing algorithms used by different nodes, errors in path calculation or manual configuration, or network topology changes during the establishment of the P2MP LSP. Such re- merges are inefficient due to the unnecessary duplication of data. Consequently one of the requirements for signaling P2MP LSPs is to choose a P2MP path that is re-merge free. In some deployments, it may also be required to signal P2MP LSPs that are both re-merge and crossover free [RFC4875]. This requirement becomes more acute to address when P2MP LSP spans multiple domains. For the purposes of this document, a domain is considered to be any collection of network elements within a common sphere of address management or path computational responsibility. Examples of such domains include Interior Gateway Protocol (IGP) areas and Autonomous Systems (ASes). This is because in an inter- domain environment, the ingress node may not have topological visibility into other domains to be able to compute and signal a re- merge free P2MP LSP. In that case, the border node for a new domain will be given one or more loose next hops for the P2MP LSP. When processing a path message, it may not have knowledge of all of the destinations of the P2MP LSP, either because S2L sub-LSPs are split between multiple Path messages, or because not all S2L sub-LSPs pass through this border node. In that case, existing protocol mechanisms do not provide sufficient information for it to be able to expand the loose hop(s) in such a way that the overall P2MP path is guaranteed to be optimal and re-merge free. This document proposes a simple procedure such that the overall P2MP LSP is re-merge free. The need for finding an end-to-end path that is re-merge free also increases chances of crankbacks during setting up P2MP LSPs as compared to their P2P counterparts. Nonetheless, crankback Ali & Neate Expires April 24, 2011 [Page 3] Internet-Draft RSVP-TE P2MP Inter-domain LSPs October 2011 mechanisms for P2MP LSPs are not addressed by [RFC4875]. [RFC5151] describes mechanisms for applying crankback to inter-domain P2P LSPs, but does not cover P2MP LSPs. This document therefore also describes how crankback signaling extensions for MPLS and GMPLS RSVP-TE defined in [RFC4920] apply to setting up P2MP TE LSPs. The solution presented in this document does not guarantee optimization of the overall P2MP tree across all domains. PCE can be used, instead, to address optimization of the overall P2MP tree. 1.1. 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. 2. Framework 2.1. Signaling Options The four signaling options defined for P2P inter-domain LSPs in [RFC4726] are also applicable to P2MP LSPs. o LSP nesting, using hierarchical LSPs [RFC4206]. o A single contiguous LSP, using the same SESSION and LSP ID along its whole path. o LSP stitching [RFC5150]. o A combination of the above. In the case of LSP nesting using hierarchical LSPs, the tunneled LSP MUST use upstream-assigned labels to ensure that the same label is used at every leaf of the H-LSP ([RFC5331], [I-D.ietf-mpls-rsvp-upstream]). The H-LSP SHOULD request non-PHP behavior and out-of-band mapping as defined in [I-D.ietf-mpls-rsvp-te-no-php-oob-mapping]. 2.2. Path Computation Techniques This document focuses on the case where the headend does not have full visibility of the topology of all domains, and is therefore not able to compute the complete P2MP tree. Rather, it has to include loose hops to traverse domains for which it does not have full visibility, and the border node(s) on entry to each domain are responsible for expanding those loose hops. Ali & Neate Expires April 24, 2011 [Page 4] Internet-Draft RSVP-TE P2MP Inter-domain LSPs October 2011 3. Signaling Procedures It is RECOMMENDED that boundary re-routing or segment-based re- routing is requested for P2MP LSPs traversing multiple domains. This is because border nodes that are expanding loose hops are typically best placed to correct any re-merge errors that occur within their domain, not the ingress node. The ingress node is RECOMMENDED to select the same border node as an ERO loose hop for all sibling S2L sub-LSPs that transit a given domain. This reduces the chances of the sibling S2L sub-LSPs being remerged, because a single border node has the necessary state to ensure that the path that they take through the domain is remerge free. 3.1. Crankback and Path Error Crankback procedures for rerouting around failures for P2P RSVP-TE LSPs are defined in [RFC4920]. These techniques can also be applied to P2MP LSPs, as decribed in this section. If a node on the path of the P2MP LSP is unable to find a route that can supply the required resources or that is re-merge free, it SHOULD generate a Path Error message for the subset of the S2L sub-LSPs which it is not able to route. For this purpose the node SHOULD try to find a minimum subset of S2L sub-LSPs for which the Path Error needs to be generated. This rule applies equally to the case where multiple S2L sub-LSPs are signaled using one Path message, as to the case where a single S2L sub-LSP is signaled in each Path message. RSVP-TE Notify messages do not include S2L_SUB_LSP objects and cannot be used to send errors for a subset of the S2L sub-LSPs in a Path message. For that reason, the node SHOULD use a Path Error message rather than a Notify message to communicate the error. In the case of a re-merge error, the node SHOULD use the error code "Routing Problem" and the error value "ERO resulted in re-merge" as specified in [RFC4875]. A border node receiving a Path Error message for a set of S2L sub- LSPs MAY hold the message and attempt to signal an alternate path through its domain for those S2L LSPs that pass through it. However, in the case of a re-merge error for which some of the re-merging S2L sub-LSPs do not pass through the border node, it SHOULD propagate the Path Error upstream to the ingress node. If the subsequent attempt is successful, the border node discards the held Path Error. If all subsequent attempts are unsuccessful, the border node SHOULD send the held Path Error upstream to the ingress node. If the ingress node receives a Path Error message with error code Ali & Neate Expires April 24, 2011 [Page 5] Internet-Draft RSVP-TE P2MP Inter-domain LSPs October 2011 "Routing Problem" and error value "ERO resulted in re-merge", then it SHOULD attempt to signal an alternate path through a different domain for the affected S2L sub-LSPs. 4. Security Considerations Security considerations and requirements from [RFC4875] and [RFC4875] apply equally to this document. Furthermore, there are some additional security considerations that may be induced by the use of "Related Addresses for Sibling S2L sub-LSP" object defined in this document. These security considerations will be added in a later version of the draft. 5. IANA Considerations Code points for "Related Addresses for Sibling S2L sub-LSP" object defined in this document will be required. Much of the details here are TBA. 6. References 6.1. Normative References [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. [RFC5151] Farrel, A., Ayyangar, A., and JP. Vasseur, "Inter-Domain MPLS and GMPLS Traffic Engineering -- Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 5151, February 2008. [RFC4920] Farrel, A., Satyanarayana, A., Iwata, A., Fujita, N., and G. Ash, "Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE", RFC 4920, July 2007. 6.2. Informative References [RFC4726] Farrel, A., Vasseur, J., and A. Ayyangar, "A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering", RFC 4726, November 2006. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Ali & Neate Expires April 24, 2011 [Page 6] Internet-Draft RSVP-TE P2MP Inter-domain LSPs October 2011 Tunnels", RFC 3209, December 2001. [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. [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. [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream Label Assignment and Context-Specific Label Space", RFC 5331, August 2008. [I-D.ietf-mpls-rsvp-upstream] Aggarwal, R. and J. Roux, "MPLS Upstream Label Assignment for RSVP-TE", draft-ietf-mpls-rsvp-upstream-05 (work in progress), March 2010. [I-D.ietf-mpls-rsvp-te-no-php-oob-mapping] Ali, Z. and G. Swallow, "Non PHP Behavior and out-of-band mapping for RSVP-TE LSPs", draft-ietf-mpls-rsvp-te-no-php-oob-mapping-04 (work in progress), March 2010. Copyright Copyright (c) 2010 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Authors' Addresses Zafar Ali (editor) Cisco Systems, Inc. Email: zali@cisco.com Nic Neate Metaswitch Networks 100 Church Street Enfield EN2 6BQ United Kingdom Email: nhn@metaswitch.com Ali & Neate Expires April 24, 2011 [Page 7]