idnits 2.17.1 draft-qin-teas-sl-rsvp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (December 28, 2016) is 2670 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-11) exists of draft-ietf-pce-pce-initiated-lsp-07 == Outdated reference: A later version (-09) exists of draft-ietf-teas-rsvp-te-scaling-rec-03 -- Obsolete informational reference (is this intentional?): RFC 7752 (Obsoleted by RFC 9552) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Qin 3 Internet-Draft D. Sun 4 Intended status: Informational J. Dong 5 Expires: July 1, 2017 X. Wei 6 M. Chen 7 Huawei Technologies 8 December 28, 2016 10 Architecture for Stateless RSVP 11 draft-qin-teas-sl-rsvp-00 13 Abstract 15 RSVP takes a "soft state" scheme to manage the reservation states in 16 routers and hosts, the soft states are created and periodically 17 refreshed by Path and Resv messages. Soft state scheme gives a 18 simple way to maintain the state synchonization between neighbors, 19 but also introduces scalability issue. This document provides a 20 framework that describes and discusses the architecture for stateless 21 RSVP (SL-RSVP), which disabled the soft-state scheme to improve the 22 protocol scalability and the other processes of RSVP are kept. This 23 document does not describe specific protocols or protocol extensions 24 needed to realize this architecture. 26 Requirements Language 28 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 29 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 30 document are to be interpreted as described in RFC 2119 [RFC2119]. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on July 1, 2017. 49 Copyright Notice 51 Copyright (c) 2016 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. Definition of SL-RSVP . . . . . . . . . . . . . . . . . . . . 3 68 2.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 4 69 2.2. Basic Idea of SL-RSVP . . . . . . . . . . . . . . . . . . 4 70 2.3. Responsbility of the Controller . . . . . . . . . . . . . 4 71 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 5 72 3.1. Generic Architecture . . . . . . . . . . . . . . . . . . 5 73 3.2. Deployment Considerations . . . . . . . . . . . . . . . . 6 74 4. Operation Overview . . . . . . . . . . . . . . . . . . . . . 6 75 4.1. LSP States Collection . . . . . . . . . . . . . . . . . . 6 76 4.2. Procedures of LSP States Deletion . . . . . . . . . . . . 6 77 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 78 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 79 7. Informative References . . . . . . . . . . . . . . . . . . . 7 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 82 1. Introduction 84 RSVP (TE) protocol[RFC2205] [RFC3209] is designed to establish 85 constraint-based LSP or QoS supported LSP that guarantee subscriber's 86 quality requriements or apply network operator's policy. The soft 87 state scheme in the protocol gives a simple way to maintain the state 88 synchronization between neighbors, but introduces scalability issue. 89 It is found that with the increase of the number of LSPs the 90 processing overhead becomes considerable. In extreme cases it is 91 possible that the bandwidth guarantee of some LSPs may not be kept 92 and that some packets are dropped even if the total bandwidth 93 requirements are smaller than the available bandwidth. 95 [RFC2961] standardizes an RSVP extension which is referred to as 96 Refresh Overhead Reduction to improve the soft-state scalability. 98 Although the refresh reduction approaches may substantially improve 99 the scalability issue, however, it has also been observed that under 100 the circumstance of huge number of LSPs (tens of thousands), the size 101 of the Srefresh may become very large, and analysis of existing 102 implementations [RFC5439] indicates that the processing required may 103 still cause significant disruption to an LSR. 105 [RFC3175] proposes to aggregate multiple reservations into a single 106 RSVP reservation across a transit domain or a routing region. 107 However, as explained in the document, aggregated RSVP sessions are 108 merely fatter RSVP reservations, when the number of session increases 109 same scalability problem as ordinary RSVP [RFC2205] will be induced. 111 Increasing the refresh time is another approach 112 [I-D.ietf-teas-rsvp-te-scaling-rec], but it should be noted that 113 regular refreshing is the nature of the soft-state scheme, when the 114 refresh interval is increasing, a degree of functionality is lost 115 [RFC5439]. Although the methods in 116 [I-D.ietf-teas-rsvp-te-scaling-rec] increases the referesh interval 117 into a fairly large value, however, the periodically refreshing is 118 not totally abolished, the protocol still relies on refreshing. 120 This document provides a framework that describes and discusses the 121 architecture for stateless RSVP (SL-RSVP), in the framework soft- 122 state scheme is disabled , the periodically refreshing of Path and 123 Resv messages will be abolished. Meanwhile, the central controller 124 (which may already exist in the network) is used to solve the 125 possibly caused problems due to the removing of the periodically 126 refreshing. It is known that, SDN provides flexibility and 127 programmability for the network to dynamically adapt to a wide range 128 of customer's requirements. Taking into account the smooth 129 transition from existing network to the new SDN enabled network, it 130 is a good choice to reuse the centralized controller of SDN. It not 131 only achieves the goal of realizing the centralized control, but also 132 leverages the existing network architecture and components. The 133 reliable message delivery mechanism specified in [RFC2961] is the 134 basis of SL-RSVP. 136 The case with TE fast reroute is not considered in SL-RSVP, it is out 137 of scope of this document. This document does not describe specific 138 protocols or protocol extensions needed to realize the framework. 140 2. Definition of SL-RSVP 141 2.1. Motivation 143 RSVP protocol has been widely depolyed in IP core, DCI and GMPLS 144 networks. Using RSVP network operators could achieve end-to-end LSP 145 tunnel management and performance guarantee. Traffic monitoring and 146 priority distinction can also be performed on intermediate nodes. 147 However, Observations of existing implementations indicate that there 148 maybe a threshold of around tens of thousands of LSPs above which an 149 LSR struggles to achieve sufficient processing to maintain LSP state. 150 As some operators' analysis, to make the PE nodes of the DCI cover 151 the main cities of the country, considering the full mesh of LSPs 152 across the PE nodes, the intermediate P nodes need to support the 153 processing of at least tens of thousands LSPs. It is a big challenge 154 to maintain the successful processing of this scale of LSPs with the 155 existing soft-state scheme. To meet the processing requirements of 156 huge number of LSPs in the near future, it is quite impending to 157 promote the scalability of RSVP. 159 2.2. Basic Idea of SL-RSVP 161 To relieve the processing burden of RSVP protocol, stateless RSVP 162 (SL-RSVP) is proposed, in which stateless means that the traditional 163 soft-state scheme in RSVP is disabled, there's no periodically 164 refreshing of Path and Resv messages and the corresponding cleanup 165 time interval is not needed. The value of the cleanup time could be 166 set zero or infinity. SL-RSVP turns RSVP from "soft-state" into 167 "hard-state". Path and Resv messges will be send only in the 168 situation that there's new changes in LSP states or requested message 169 retransmission. SL-RSVP is based on acknowledgement and reliable 170 RSVP message transmissions as defined in [RFC2961]. Meanwhile, 171 leveraging the existing central controller like the controller in SDN 172 network to solve the possibly caused problems when the refreshing is 173 removed. The central controller in SL-RSVP only do the compensating 174 works, the signaling process is not the work of the controller. 175 Signaling will be executed in every node along the LSP as traditional 176 RSVP does. 178 2.3. Responsbility of the Controller 180 In RSVP protocol, with soft-state approach, the LSP states on every 181 LSR will be periodically refreshed by Path and Resv messages. After 182 a state change or at the expiration of each "refresh timeout", RSVP 183 scans its states to forward or build Path and Resv refresh messages 184 to succeeding hops. The functionality of soft-state scheme is to 185 keep states consistency on each LSR along the LSP. When the soft- 186 state scheme is disabled in SL-RSVP, the problem need to handle is 187 the potential inconsistency of states that caused by the occasional 188 message losses during the transmission. The controller will be used 189 to solve this problem. In the case of Path or Resv message loss, 190 when the retransmission limit Rl as specified in section 6[RFC2961] 191 has been reached, the router may start periodic retransmission of 192 these messages. This periodic retransmission should continue until 193 an appropriate acknowledgement of the retransmitted Path/Resv message 194 is received, during this time the controller need no action. When 195 PathTear or ResvTear message is lost, it will cause residual states 196 on the nodes that behind the lost position. Usually these residual 197 states will be deleted after the expiration of the cleanup timeout 198 interval in RSVP, but when there's no refresh and cleanup timeout 199 interval, these residual states could not be deleted. In SL-RSVP, it 200 is the responsibility of the controller to help with the deletion of 201 the residual RSVP states on the nodes along the LSP. 203 In SL-RSVP, by leveraging the controller, the LSRs can be released 204 from soft-state maintenance. As the signaling is still based on 205 RSVP, so it is easy to meet the requirements of network evolution. 207 3. Architecture 209 This section gives the architecture of SL-RSVP, the considerations 210 and conclusions described in the previous section lead to the 211 architecture described in this section. 213 3.1. Generic Architecture 215 The following diagram illustrates the SL-RSVP architecture. The 216 controller locates external to the requesting network nodes, its 217 functionality is to help deleting the residual RSVP states on the 218 nodes. There's no periodically refreshing between neighbor LSRs 219 while keeping the other process of RSVP. When the controller 220 perceives the failure of one LSP, it will issue deleting instructions 221 to every LSR of the LSP, so it needs to have logical sessions with 222 each of the node in the network to enable the deleting process. In 223 the controller, LSP-Database and TE-Database are maintained. 225 +------------------------------------------------+ 226 | SL-RSVP controller | 227 | +-------------------------------------+ | 228 | | +---------+ +---------+ | | 229 | | | LSP-DB | | TE-DB | | | 230 | | +---------+ +---------+ | | 231 | ^-------------------------------------^ | 232 | | | | | 233 | V V V | 234 | +------+ RSVP +------+ RSVP +------+ | 235 | |Node 1| ........ |Node 2| ........ |Node 3| | 236 | +------+ no refresh+------+ no refresh+------+ | 237 +------------------------------------------------+ 238 Figure 1. Architecture of SL-RSVP 240 3.2. Deployment Considerations 242 There exists different kinds of depolyment architecture in network 243 which differs in reliability and deployment complexity. No matter 244 using which kind architecture, message acknowledgement scheme is 245 needed to ensure the reliable communication between the controller 246 and the LSRs. 248 4. Operation Overview 250 4.1. LSP States Collection 252 Using RSVP protocol, the LSPs can be created by the head-end LSR or 253 the controller (like PCE [I-D.ietf-pce-pce-initiated-lsp]). No 254 matter in which situation, LSP states reporting process is 255 compulsory, both the head-end LSR and the other nodes along the LSP 256 should report the LSPs' states to the controller, only the controller 257 have the LSPs' states information it can help deleting the residual 258 states on LSP nodes. The report of LSP states may be based on 259 existing protocols such as BGP-LS[RFC7752], PCEP[RFC5440], etc. By 260 comparing the states reported by the head-end LSR and the other LSRs 261 the controller can know the location of the residual states. 263 4.2. Procedures of LSP States Deletion 265 The capability of deleting the LSP states needs to be negotiated at 266 the beginning of the session between the controller and the nodes to 267 determine whether the controller can help with the deletion. When 268 there's failure on an LSP, the LSP initiator may try to tear the LSP. 269 Due to the failure, PathTear/ResvTear messages may not be 270 successfully delivered, it could cause residual states on some nodes 271 of the LSP. In this situation, when the controller perceives the LSP 272 failure and gets the permission of deletion by the LSP initiator, it 273 identifies the nodes which contain residual states and then send the 274 deletion messages. The LSP failure can be perceived by the 275 controller through interior gateway protocol, OAM or intermediate 276 nodes reporting. When the residual states on the nodes has been 277 successfully deleted, acknowledgement messages need to be sent to the 278 controller. To keep the reliability of the session between the 279 controller and the intermediate nodes of the LSPs, survivability 280 schemes need to be used. 282 The controller could do the deletion process later after perceiving 283 the LSP failure. In other words, the LSP state deletion could be 284 delayed by the controller. The delay time can be determined by 285 operator. Delay deleting is helpful to avoid the performance 286 bottleneck of the controller caused by numerous concurrent deleting 287 request. 289 In the situation of session failure between the controller and the 290 LSRs or unexpected breakdown of the controller or LSRs, a state 291 synchronization process is indispensable after the recovery. The 292 residual states found after synchornization will be deleted. In 293 normal cases, when finding residual LSP states the controller will 294 send deletion messages to the LSRs of the LSP directly to delete the 295 residual states. 297 5. Security Considerations 299 TBD. 301 6. Acknowledgements 303 TBD. 305 7. Informative References 307 [I-D.ietf-pce-pce-initiated-lsp] 308 Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 309 Extensions for PCE-initiated LSP Setup in a Stateful PCE 310 Model", draft-ietf-pce-pce-initiated-lsp-07 (work in 311 progress), July 2016. 313 [I-D.ietf-teas-rsvp-te-scaling-rec] 314 Beeram, V., Minei, I., Shakir, R., Pacella, D., and T. 315 Saad, "Implementation Recommendations to Improve the 316 Scalability of RSVP-TE Deployments", draft-ietf-teas-rsvp- 317 te-scaling-rec-03 (work in progress), October 2016. 319 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 320 Requirement Levels", BCP 14, RFC 2119, 321 DOI 10.17487/RFC2119, March 1997, 322 . 324 [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. 325 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 326 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, 327 September 1997, . 329 [RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., 330 and S. Molendini, "RSVP Refresh Overhead Reduction 331 Extensions", RFC 2961, DOI 10.17487/RFC2961, April 2001, 332 . 334 [RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, 335 "Aggregation of RSVP for IPv4 and IPv6 Reservations", 336 RFC 3175, DOI 10.17487/RFC3175, September 2001, 337 . 339 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 340 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 341 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 342 . 344 [RFC5439] Yasukawa, S., Farrel, A., and O. Komolafe, "An Analysis of 345 Scaling Issues in MPLS-TE Core Networks", RFC 5439, 346 DOI 10.17487/RFC5439, February 2009, 347 . 349 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 350 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 351 DOI 10.17487/RFC5440, March 2009, 352 . 354 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 355 S. Ray, "North-Bound Distribution of Link-State and 356 Traffic Engineering (TE) Information Using BGP", RFC 7752, 357 DOI 10.17487/RFC7752, March 2016, 358 . 360 Authors' Addresses 361 Jun Qin 362 Huawei Technologies 363 Huawei Campus, No. 156 Beiqing Rd. 364 Beijing 100095 365 China 367 Email: qinjun4@huawei.com 369 Dongzhi Sun 370 Huawei Technologies 371 Huawei Campus, No. 156 Beiqing Rd. 372 Beijing 100095 373 China 375 Email: sundongzhi@huawei.com 377 Jie Dong 378 Huawei Technologies 379 Huawei Campus, No. 156 Beiqing Rd. 380 Beijing 100095 381 China 383 Email: jie.dong@huawei.com 385 Xiugang Wei 386 Huawei Technologies 387 Huawei Campus, No. 156 Beiqing Rd. 388 Beijing 100095 389 China 391 Email: weixiugang@huawei.com 393 Mach Chen 394 Huawei Technologies 395 Huawei Campus, No. 156 Beiqing Rd. 396 Beijing 100095 397 China 399 Email: mach.chen@huawei.com