idnits 2.17.1 draft-zhaoyl-pce-flexi-grid-pcep-ex-01.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 date (April 25, 2012) is 4382 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC5440' is defined on line 429, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group YL. Zhao 3 Internet-Draft J. Zhang 4 Intended status: Informational TT. Peng 5 Expires: October 27, 2012 XS. Yu 6 BUPT 7 XP. Cao 8 DJ. Wang 9 XH. Fu 10 ZTE Corporation 11 April 25, 2012 13 PCEP Protocol Extension for spectrum utilization optimization in Flexi- 14 Grid Networks 15 draft-zhaoyl-pce-flexi-grid-pcep-ex-01 17 Abstract 19 Flexi-grid networks overcomes the fixed grid channel of Wavelength 20 Switched Optical Network(WSON) by flexible spectrum to allow non- 21 uniform and dynamic allocation of spectrum based on the demand of the 22 incoming services' LSP. Flexi-grid networks is an effective solution 23 to solve the problem of efficient spectrum utilization. 25 Because the client LSP needs to be assigned contiguous spectrum in 26 flexi-grid networks, there will be two problems that would affect 27 spectrum utilization, i.e. RSA and fragmentation. We introduce two 28 kinds of methods which can improve the spectrum utilization further, 29 and some related PCEP extensions are defined in this document. 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on October 27, 2012. 48 Copyright Notice 49 Copyright (c) 2012 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 66 3. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 3 67 4. RSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 4.1. Introduction of RSA . . . . . . . . . . . . . . . . . . . 4 69 4.2. Algorithms of RSA . . . . . . . . . . . . . . . . . . . . 4 70 4.3. RSA Schemes Selection . . . . . . . . . . . . . . . . . . 5 71 5. Defragmentation . . . . . . . . . . . . . . . . . . . . . . . 6 72 5.1. Motivation of Defragmentation . . . . . . . . . . . . . . 6 73 5.2. Definition of Defragmentation . . . . . . . . . . . . . . 6 74 5.3. Application Scene of Defragmentation . . . . . . . . . . . 6 75 6. PCEP Protocol Extension . . . . . . . . . . . . . . . . . . . 7 76 6.1. PCEP Protocol Extension for RSA . . . . . . . . . . . . . 7 77 6.2. PCEP Protocol Extension for Defragmentation . . . . . . . 9 78 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 79 8. Normative References . . . . . . . . . . . . . . . . . . . . . 11 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 82 1. Introduction 84 Demand of traffic is increasing exponentially and already approaching 85 the limit of single mode fiber capacity. At the same time, because 86 of varying demand of trafficGBP[not]we need an efficient and agile 87 utilization of the optical spectrum. 89 ITU-T Study Group 15 introduce a new flexi-grid networks to enable 90 dynamic allocation of spectrum resource. The flexi-grid networks is 91 an effective solution to solve the problem of efficient spectrum 92 resource utilization. 94 The granularity of flexi-grid networks can be smaller and agile. 95 i.e.(6.25GHz).In the flexi-grid networks, the appropriate size of 96 spectrum is determined by the used modulation format.According to the 97 client data rate request and physical constraints of the selected 98 path,the appropriate size of spectrum is adaptively allocated to 99 optical connections by assigning the appropriate number of contiguous 100 spectrum from end-to-end.Before assigning the client request, we have 101 to find suitable route and fit contiguous spectrum for it, and it is 102 a complex process. So spectrum utilization is very important in RSA. 103 While there are several algorithms for RSA, so flexi-grid networks 104 require to extend PCEP protocol to support different algorithms 105 seletion. 107 Upon tearing down of connections, allocated spectrum are released for 108 future requests. In a dynamic traffic scenario, this channel setup 109 and tear down processes leads to fragmentation of spectral resources. 110 Due to the fragmentation, the available spectrum divide into small 111 noncontiguous spectral bands,the spectral effciency in the network is 112 compromised. Therefore the probability of finding suffcient 113 contiguous spectrum for a connection is decreased. We introduce 114 Spectrum Fragments Cascading and Defragmentation to deal with 115 fragmentation in flexi-grid networks. So PCEP protocol have to add 116 some messages to support them. 118 2. Conventions Used in This Document 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in [RFC2119]. 124 3. Terminologies 126 RSA: Routing and Spectrum Assignment 127 WSON:Wavelength Switched Optical Network 129 SFC:Spectrum Fragments Cascading 131 4. RSA 133 4.1. Introduction of RSA 135 This part we focuses on the routing and spectrum assignment (RSA) 136 problem. This problem can be partitioned into two subproblems - (1) 137 routing and (2) wavelength assignment and each subproblem can be 138 solved separately. Different from traditional WDM network, flexi- 139 grid networks assign continuous spectrum for new arrival request. 140 Static planning models used for flexi-grid networks to improve 141 spectrum utilization. 143 4.2. Algorithms of RSA 145 There are several spectrum assignment algorithms. 147 (1)Random Fit (RF) 149 This scheme first searches the space of wavelengths to determine the 150 set of all spectrum that are available on the required route. Among 151 the available wavelengths, one is chosen randomly. 153 (2)First-Fit (FF) 155 In this scheme, all spectrum is numbered.When searching for available 156 spectrum, a lower numbered spectrum is considered before a higher- 157 numbered spectrum.The first available spectrum is then selected. 158 Compared to Random spectrum assignment, the computation cost of this 159 scheme is lower because there is no need to search the entire 160 spectrum space for each route. 162 (3)Least-Used (LU)/SPREAD 164 LU selects the spectrum that is the least used in the network, 165 thereby attempting to balance the load among all the spectrum. The 166 performance of LU is worse than Random, while also introducing 167 additional communication overhead (e.g., global information is 168 required to compute the least-used spectrum). 170 (4)Most-Used (MU)/PACK 172 MU is the opposite of LU in that it attempts to select the most-used 173 spectrum in the network. The communication overhead, storage, and 174 computation cost are all similar to those in LU.MU also slightly 175 outperforms FF, doing a better job of packing connections into fewer 176 wavelengths and conserving the spare capacity of less-used 177 wavelengths. 179 (5)Min-Product (MP) 181 MU is the opposite of LU works. In a single fiber network, MP 182 becomes FF. The goal of MP is to pack wavelengths into fibers, 183 thereby minimizing the number of fibers in the network. 185 (6)Least-Loaded (LL) 187 The LL heuristic, like MP, is also designed for multi-fiber networks. 188 This heuristic selects the spectrum that has the largest residual 189 capacity on the most loaded link along route. 191 (7)MAX-SUM (MS) 193 MS was proposed for multi-fiber networks but it can also be applied 194 to the single-fiber case.MS considers all possible paths in the 195 network and attempts to maximize the remaining path capacities after 196 lightpath establishment. 198 (8)Relative Capacity Loss (RCL) 200 RCL is based on MS. RCL chooses spectrum to minimize the relative 201 capacity loss. RCL is based on the observation that minimizing total 202 capacity loss sometimes does not lead to the best choice of spectrum. 204 (9)Spectrum Reservation (Rsv) 206 In Rsv, a given spectrum on a specified link is reserved for a 207 traffic stream, usually a multihop stream. This scheme reduces the 208 blocking for multihop traffic,while increasing the blocking for 209 connections that traverse only one fiber link (single-hop traffic). 211 (10)Protecting Threshold (Thr) 213 In Thr, a single-hop connection is assigned spectrum only if the 214 number of idle spectrum on the link is at or above a given threshold. 216 4.3. RSA Schemes Selection 218 There are several spectrum assignment algorithms , we have to choose 219 one of them for use in flexi-grid networks. Diffrent RSA schemes 220 selected according to diffrent network condition. The PCEP protocol 221 need to extend a bit that provide different Schemes to choose. 223 5. Defragmentation 225 5.1. Motivation of Defragmentation 227 New arrival of requests are then either forced to utilize more 228 spectrum in the network or blocked in spite of suffcient spectrum 229 being available. Additionally, as the network evolves, a current 230 optimal routing scheme might no longer provide the optimal spectral 231 utilization over time. There is an increasing demand from the 232 network operators to be able to periodically recon?gure the network 233 and return it to its optimal state, so that the network can operate 234 more effciently. 236 5.2. Definition of Defragmentation 238 There is an operation defined as network defragmentation to solve 239 above problem. Reducing the blocking by consolidating the available 240 network resources, this operation will also enable better network 241 maintenance and more effcient network restoration and bandwidth 242 adjustment. 244 5.3. Application Scene of Defragmentation 246 The process of defragmentation: (1) select which LSP to 247 defragmentation, interrupt it, (2) choose forward spectrum in 248 original route or new route, (3) move the LSP on possible spectrum. 250 An example of defragentation is as following: A,B,C are client LSPs 251 on link l, l1 is Original statement of link l,l2 is statement of link 252 l after defragementation. 254 +-------------+ +----+ +---------+ 255 l1: | A | | B | | C | 256 +-------------+----------+----+-----+---------+-- 257 +-------------+----+-----------+ 258 l2: | A | B | C | 259 +-------------+----+-----------+----- 261 we first focus on the problem of the time-point when should 262 defragmentation be operated. So far, two new concepts proposed to 263 solve this problem. One concept is Utilization Entropy that 264 represents the level of resource fragmentation in an optical network 265 proposed by Fujitsu Labs of America; the other concept is Spectrum 266 Compactness that represents the spectrum distribution state in a link 267 or in the network proposed by State key Laboratory of Information 268 Photonics and Optical Communications of Beijing University of Posts 269 and Telecommunications. These two methods both related to threshold, 270 it necessary to set threshold, when reaching threshold triggered 271 defragmentation. PCEP protocol should include these information. 273 we consider the methods of defragmentation. At present, there are 274 two methods for defragmentation. First is change route of client LSP 275 means the spectrum of this LSP in new route is ahead than the 276 spectrum in original route. Second is the LSP move forward directly 277 in original route. 279 Defragmentation has to interrupt the traffic; the application scene 280 is leisure network. When the network is busy, defragmentation lead 281 to the increase of interrupt traffic demands. 283 Before defragmentation for the network, we have to do static 284 programming for existing traffic demand in the network. We hope the 285 defragmentation result reach or approach the static programming. 287 Maybe some network has requirement of interrupting rate or 288 defragmentation time and so on, we should provide corresponding 289 information to meet above requirements. 291 6. PCEP Protocol Extension 293 6.1. PCEP Protocol Extension for RSA 295 The PCEP protocol need to be extended to support the Algorithms 296 choosing of RSA. PCReq need to adding RAEO-list information. This 297 information include "Algorithm Id", which stand for the number of 298 different algorithms, and "Pri" that means priority of these 299 algorithms. 301 ::= 302 303 [] 304 [] 305 [] 306 [] 307 [[]] 308 [] 309 [] 311 [] defined as follows: 312 0 1 2 3 313 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | Object-Class | OT |Res|P|I| Object Length (bytes) | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | Flags | Algorithm Id | Pri | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | | 320 // Optional TLVs // 321 | | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 [] defined as follows: 325 0 1 2 3 326 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | Object-Class | OT |Res|P|I| Object Length (bytes) | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | Flags | Algorithm Id | Pri | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | | 333 // Optional TLVs // 334 | | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 ::= 338 [] 339 [] 340 [] 341 NO-PATH: 342 0 1 2 3 343 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 |Nature of Issue|C| Flags | Reserved | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | | 348 // Optional TLVs // 349 | | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 Figure 11: NO-PATH Object Format 352 NI - Nature of Issue (8 bits): The NI field is used to report the 353 nature of the issue that led to a negative reply. 354 Two values are currently defined: 355 0: No path satisfying the set of constraints could be found 356 1: PCE chain broken 357 2: No path satisfying the Continuous spectrum 359 6.2. PCEP Protocol Extension for Defragmentation 361 The presence of defragmentation in Flexi-Grid Networks has an impact 362 on the information that needs to be transferred by the control plane 363 and the PCE. Defragmentation has to interrupt the traffic and move 364 it to another spectrum or route. The PCEP protocol needs to be 365 extended two messages to support defragmentation, including 366 information of original route/spectrum and present route/spectrum, 367 when to stop defragmentation, the selection of methods and the limit 368 of corresponding factors and so on. 370 Here is Spectrum Defragmentation Request Message and Spectrum 371 Defragmentation Reply Message. "Target Clutter Value" stand for the 372 threshold of defragmentation. "R" means whether the network MUST 373 make it."Id 1" is number of defragmentation methods, "Id 2" is number 374 of methods to trigger defragmentation, "L" means limit of 375 interrupting rate or defragmentation time. 377 ::= 378 379 [LSPA Object] 380 [] 382 Spectrum Defragmentation Reply Message 384 ::= 385 386 [LSPA Object] 387 [] 389 Spectrum Defragmentation Reply Message 391 SDTO: Spectrum Defragmentation Target Object 393 defined as follows: 394 0 1 2 3 395 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | Object-Class | OT |Res|P|I| Object Length (bytes) | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | Flags | L |Id1|Id2|R| Pri | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 | Target Clutter Value | 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 | | 404 // Optional TLVs // 405 | | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 ::= 409
410
411 where Center Frequence is 412 0 1 2 3 413 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | Center Frequence | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 Center Frequence: The requested bandwidth is encoded in 32 bits, 418 expressed in bytes per second. 420 7. Security Considerations 422 TBD. 424 8. Normative References 426 [RFC2119] Bradner, S., "Key words for use in RFC's to Indicate 427 Requirement Levels", RFC 2119, March 1997. 429 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element 430 (PCE) Communication Protocol (PCEP)", RFC 5440, 431 March 2009. 433 Authors' Addresses 435 Yongli Zhao 436 BUPT 437 No.10,Xitucheng Road,Haidian District 438 Beijing 100876 439 P.R.China 441 Phone: +8613811761857 442 Email: yonglizhao@bupt.edu.cn 443 URI: http://www.bupt.edu.cn/ 445 Jie Zhang 446 BUPT 447 No.10,Xitucheng Road,Haidian District 448 Beijing 100876 449 P.R.China 451 Phone: +8613911060930 452 Email: lgr24@bupt.edu.cn 453 URI: http://www.bupt.edu.cn/ 454 Tiantian Peng 455 BUPT 456 No.10,Xitucheng Road,Haidian District 457 Beijing 100876 458 P.R.China 460 Phone: +8615116984347 461 Email: tt871228@163.com 462 URI: http://www.bupt.edu.cn/ 464 Xiaosong Yu 465 BUPT 466 No.10,Xitucheng Road,Haidian District 467 Beijing 100876 468 P.R.China 470 Phone: +8613811731723 471 Email: yu.xiaosong@qq.com 472 URI: http://www.bupt.edu.cn/ 474 Xuping Cao 475 ZTE Corporation 476 No.16,Huayuan Road,Haidian District 477 Beijing 100191 478 P.R.China 480 Phone: +8615801379189 481 Email: cao.xuping@zte.com.cn 482 URI: http://www.zte.com.cn/ 484 Dajiang Wang 485 ZTE Corporation 486 No.16,Huayuan Road,Haidian District 487 Beijing 100191 488 P.R.China 490 Phone: +8613811795408 491 Email: wang.dajiang@zte.com.cn 492 URI: http://www.zte.com.cn/ 493 Xihua Fu 494 ZTE Corporation 495 West District,ZTE Plaza,No.10,Tangyan South Road,Gaoxin District 496 Xi'an 710065 497 P.R.China 499 Phone: +8613798412242 500 Email: fu.xihua@zte.com.cn 501 URI: http://www.zte.com.cn/