Network Working Group J. Qin Internet-Draft D. Sun Intended status: Informational J. Dong Expires: July 1, 2017 X. Wei M. Chen Huawei Technologies December 28, 2016 Architecture for Stateless RSVP draft-qin-teas-sl-rsvp-00 Abstract RSVP takes a "soft state" scheme to manage the reservation states in routers and hosts, the soft states are created and periodically refreshed by Path and Resv messages. Soft state scheme gives a simple way to maintain the state synchonization between neighbors, but also introduces scalability issue. This document provides a framework that describes and discusses the architecture for stateless RSVP (SL-RSVP), which disabled the soft-state scheme to improve the protocol scalability and the other processes of RSVP are kept. This document does not describe specific protocols or protocol extensions needed to realize this architecture. Requirements Language 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 [RFC2119]. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on July 1, 2017. Qin, et al. Expires July 1, 2017 [Page 1] Internet-Draft SL-RSVP December 2016 Copyright Notice Copyright (c) 2016 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Definition of SL-RSVP . . . . . . . . . . . . . . . . . . . . 3 2.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Basic Idea of SL-RSVP . . . . . . . . . . . . . . . . . . 4 2.3. Responsbility of the Controller . . . . . . . . . . . . . 4 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Generic Architecture . . . . . . . . . . . . . . . . . . 5 3.2. Deployment Considerations . . . . . . . . . . . . . . . . 6 4. Operation Overview . . . . . . . . . . . . . . . . . . . . . 6 4.1. LSP States Collection . . . . . . . . . . . . . . . . . . 6 4.2. Procedures of LSP States Deletion . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 7. Informative References . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction RSVP (TE) protocol[RFC2205] [RFC3209] is designed to establish constraint-based LSP or QoS supported LSP that guarantee subscriber's quality requriements or apply network operator's policy. The soft state scheme in the protocol gives a simple way to maintain the state synchronization between neighbors, but introduces scalability issue. It is found that with the increase of the number of LSPs the processing overhead becomes considerable. In extreme cases it is possible that the bandwidth guarantee of some LSPs may not be kept and that some packets are dropped even if the total bandwidth requirements are smaller than the available bandwidth. [RFC2961] standardizes an RSVP extension which is referred to as Refresh Overhead Reduction to improve the soft-state scalability. Qin, et al. Expires July 1, 2017 [Page 2] Internet-Draft SL-RSVP December 2016 Although the refresh reduction approaches may substantially improve the scalability issue, however, it has also been observed that under the circumstance of huge number of LSPs (tens of thousands), the size of the Srefresh may become very large, and analysis of existing implementations [RFC5439] indicates that the processing required may still cause significant disruption to an LSR. [RFC3175] proposes to aggregate multiple reservations into a single RSVP reservation across a transit domain or a routing region. However, as explained in the document, aggregated RSVP sessions are merely fatter RSVP reservations, when the number of session increases same scalability problem as ordinary RSVP [RFC2205] will be induced. Increasing the refresh time is another approach [I-D.ietf-teas-rsvp-te-scaling-rec], but it should be noted that regular refreshing is the nature of the soft-state scheme, when the refresh interval is increasing, a degree of functionality is lost [RFC5439]. Although the methods in [I-D.ietf-teas-rsvp-te-scaling-rec] increases the referesh interval into a fairly large value, however, the periodically refreshing is not totally abolished, the protocol still relies on refreshing. This document provides a framework that describes and discusses the architecture for stateless RSVP (SL-RSVP), in the framework soft- state scheme is disabled , the periodically refreshing of Path and Resv messages will be abolished. Meanwhile, the central controller (which may already exist in the network) is used to solve the possibly caused problems due to the removing of the periodically refreshing. It is known that, SDN provides flexibility and programmability for the network to dynamically adapt to a wide range of customer's requirements. Taking into account the smooth transition from existing network to the new SDN enabled network, it is a good choice to reuse the centralized controller of SDN. It not only achieves the goal of realizing the centralized control, but also leverages the existing network architecture and components. The reliable message delivery mechanism specified in [RFC2961] is the basis of SL-RSVP. The case with TE fast reroute is not considered in SL-RSVP, it is out of scope of this document. This document does not describe specific protocols or protocol extensions needed to realize the framework. 2. Definition of SL-RSVP Qin, et al. Expires July 1, 2017 [Page 3] Internet-Draft SL-RSVP December 2016 2.1. Motivation RSVP protocol has been widely depolyed in IP core, DCI and GMPLS networks. Using RSVP network operators could achieve end-to-end LSP tunnel management and performance guarantee. Traffic monitoring and priority distinction can also be performed on intermediate nodes. However, Observations of existing implementations indicate that there maybe a threshold of around tens of thousands of LSPs above which an LSR struggles to achieve sufficient processing to maintain LSP state. As some operators' analysis, to make the PE nodes of the DCI cover the main cities of the country, considering the full mesh of LSPs across the PE nodes, the intermediate P nodes need to support the processing of at least tens of thousands LSPs. It is a big challenge to maintain the successful processing of this scale of LSPs with the existing soft-state scheme. To meet the processing requirements of huge number of LSPs in the near future, it is quite impending to promote the scalability of RSVP. 2.2. Basic Idea of SL-RSVP To relieve the processing burden of RSVP protocol, stateless RSVP (SL-RSVP) is proposed, in which stateless means that the traditional soft-state scheme in RSVP is disabled, there's no periodically refreshing of Path and Resv messages and the corresponding cleanup time interval is not needed. The value of the cleanup time could be set zero or infinity. SL-RSVP turns RSVP from "soft-state" into "hard-state". Path and Resv messges will be send only in the situation that there's new changes in LSP states or requested message retransmission. SL-RSVP is based on acknowledgement and reliable RSVP message transmissions as defined in [RFC2961]. Meanwhile, leveraging the existing central controller like the controller in SDN network to solve the possibly caused problems when the refreshing is removed. The central controller in SL-RSVP only do the compensating works, the signaling process is not the work of the controller. Signaling will be executed in every node along the LSP as traditional RSVP does. 2.3. Responsbility of the Controller In RSVP protocol, with soft-state approach, the LSP states on every LSR will be periodically refreshed by Path and Resv messages. After a state change or at the expiration of each "refresh timeout", RSVP scans its states to forward or build Path and Resv refresh messages to succeeding hops. The functionality of soft-state scheme is to keep states consistency on each LSR along the LSP. When the soft- state scheme is disabled in SL-RSVP, the problem need to handle is the potential inconsistency of states that caused by the occasional message losses during the transmission. The controller will be used Qin, et al. Expires July 1, 2017 [Page 4] Internet-Draft SL-RSVP December 2016 to solve this problem. In the case of Path or Resv message loss, when the retransmission limit Rl as specified in section 6[RFC2961] has been reached, the router may start periodic retransmission of these messages. This periodic retransmission should continue until an appropriate acknowledgement of the retransmitted Path/Resv message is received, during this time the controller need no action. When PathTear or ResvTear message is lost, it will cause residual states on the nodes that behind the lost position. Usually these residual states will be deleted after the expiration of the cleanup timeout interval in RSVP, but when there's no refresh and cleanup timeout interval, these residual states could not be deleted. In SL-RSVP, it is the responsibility of the controller to help with the deletion of the residual RSVP states on the nodes along the LSP. In SL-RSVP, by leveraging the controller, the LSRs can be released from soft-state maintenance. As the signaling is still based on RSVP, so it is easy to meet the requirements of network evolution. 3. Architecture This section gives the architecture of SL-RSVP, the considerations and conclusions described in the previous section lead to the architecture described in this section. 3.1. Generic Architecture The following diagram illustrates the SL-RSVP architecture. The controller locates external to the requesting network nodes, its functionality is to help deleting the residual RSVP states on the nodes. There's no periodically refreshing between neighbor LSRs while keeping the other process of RSVP. When the controller perceives the failure of one LSP, it will issue deleting instructions to every LSR of the LSP, so it needs to have logical sessions with each of the node in the network to enable the deleting process. In the controller, LSP-Database and TE-Database are maintained. Qin, et al. Expires July 1, 2017 [Page 5] Internet-Draft SL-RSVP December 2016 +------------------------------------------------+ | SL-RSVP controller | | +-------------------------------------+ | | | +---------+ +---------+ | | | | | LSP-DB | | TE-DB | | | | | +---------+ +---------+ | | | ^-------------------------------------^ | | | | | | | V V V | | +------+ RSVP +------+ RSVP +------+ | | |Node 1| ........ |Node 2| ........ |Node 3| | | +------+ no refresh+------+ no refresh+------+ | +------------------------------------------------+ Figure 1. Architecture of SL-RSVP 3.2. Deployment Considerations There exists different kinds of depolyment architecture in network which differs in reliability and deployment complexity. No matter using which kind architecture, message acknowledgement scheme is needed to ensure the reliable communication between the controller and the LSRs. 4. Operation Overview 4.1. LSP States Collection Using RSVP protocol, the LSPs can be created by the head-end LSR or the controller (like PCE [I-D.ietf-pce-pce-initiated-lsp]). No matter in which situation, LSP states reporting process is compulsory, both the head-end LSR and the other nodes along the LSP should report the LSPs' states to the controller, only the controller have the LSPs' states information it can help deleting the residual states on LSP nodes. The report of LSP states may be based on existing protocols such as BGP-LS[RFC7752], PCEP[RFC5440], etc. By comparing the states reported by the head-end LSR and the other LSRs the controller can know the location of the residual states. 4.2. Procedures of LSP States Deletion The capability of deleting the LSP states needs to be negotiated at the beginning of the session between the controller and the nodes to determine whether the controller can help with the deletion. When there's failure on an LSP, the LSP initiator may try to tear the LSP. Due to the failure, PathTear/ResvTear messages may not be successfully delivered, it could cause residual states on some nodes of the LSP. In this situation, when the controller perceives the LSP failure and gets the permission of deletion by the LSP initiator, it Qin, et al. Expires July 1, 2017 [Page 6] Internet-Draft SL-RSVP December 2016 identifies the nodes which contain residual states and then send the deletion messages. The LSP failure can be perceived by the controller through interior gateway protocol, OAM or intermediate nodes reporting. When the residual states on the nodes has been successfully deleted, acknowledgement messages need to be sent to the controller. To keep the reliability of the session between the controller and the intermediate nodes of the LSPs, survivability schemes need to be used. The controller could do the deletion process later after perceiving the LSP failure. In other words, the LSP state deletion could be delayed by the controller. The delay time can be determined by operator. Delay deleting is helpful to avoid the performance bottleneck of the controller caused by numerous concurrent deleting request. In the situation of session failure between the controller and the LSRs or unexpected breakdown of the controller or LSRs, a state synchronization process is indispensable after the recovery. The residual states found after synchornization will be deleted. In normal cases, when finding residual LSP states the controller will send deletion messages to the LSRs of the LSP directly to delete the residual states. 5. Security Considerations TBD. 6. Acknowledgements TBD. 7. Informative References [I-D.ietf-pce-pce-initiated-lsp] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP Extensions for PCE-initiated LSP Setup in a Stateful PCE Model", draft-ietf-pce-pce-initiated-lsp-07 (work in progress), July 2016. [I-D.ietf-teas-rsvp-te-scaling-rec] Beeram, V., Minei, I., Shakir, R., Pacella, D., and T. Saad, "Implementation Recommendations to Improve the Scalability of RSVP-TE Deployments", draft-ietf-teas-rsvp- te-scaling-rec-03 (work in progress), October 2016. Qin, et al. Expires July 1, 2017 [Page 7] Internet-Draft SL-RSVP December 2016 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, September 1997, . [RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., and S. Molendini, "RSVP Refresh Overhead Reduction Extensions", RFC 2961, DOI 10.17487/RFC2961, April 2001, . [RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175, DOI 10.17487/RFC3175, September 2001, . [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, . [RFC5439] Yasukawa, S., Farrel, A., and O. Komolafe, "An Analysis of Scaling Issues in MPLS-TE Core Networks", RFC 5439, DOI 10.17487/RFC5439, February 2009, . [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009, . [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and S. Ray, "North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP", RFC 7752, DOI 10.17487/RFC7752, March 2016, . Authors' Addresses Qin, et al. Expires July 1, 2017 [Page 8] Internet-Draft SL-RSVP December 2016 Jun Qin Huawei Technologies Huawei Campus, No. 156 Beiqing Rd. Beijing 100095 China Email: qinjun4@huawei.com Dongzhi Sun Huawei Technologies Huawei Campus, No. 156 Beiqing Rd. Beijing 100095 China Email: sundongzhi@huawei.com Jie Dong Huawei Technologies Huawei Campus, No. 156 Beiqing Rd. Beijing 100095 China Email: jie.dong@huawei.com Xiugang Wei Huawei Technologies Huawei Campus, No. 156 Beiqing Rd. Beijing 100095 China Email: weixiugang@huawei.com Mach Chen Huawei Technologies Huawei Campus, No. 156 Beiqing Rd. Beijing 100095 China Email: mach.chen@huawei.com Qin, et al. Expires July 1, 2017 [Page 9]