idnits 2.17.1 draft-xu-actn-perf-dynamic-service-control-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 120 has weird spacing: '...itoring mecha...' -- The document date (February 13, 2014) is 3697 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-07) exists of draft-ceccarelli-actn-framework-00 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Yunbin Xu 2 Internet Draft CATR 3 Intended status: Informational 4 Expires: August2014 5 Guoying Zhang 6 CATR 8 Weiqiang Cheng 9 CMCC 11 Haomian zheng 12 Huawei 14 February 13, 2014 16 Use Cases and Requirements of Dynamic Service Control based on 17 Performance Monitoring in ACTN Architecture 18 draft-xu-actn-perf-dynamic-service-control-00.txt 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six 31 months and may be updated, replaced, or obsoleted by other documents 32 at any time. It is inappropriate to use Internet-Drafts as 33 reference material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed 36 at http://www.ietf.org/ietf/1id-abstracts.txt 38 The list of Internet-Draft Shadow Directories can be accessed 39 at http://www.ietf.org/shadow.html 41 This Internet-Draft will expire on August 10, 2014. 43 Copyright Notice 45 Copyright (c) 2014 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info)in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with 53 respect to this document. Code Components extracted from this 54 document must include Simplified BSD License text as described in 55 Section 4.e of the Trust Legal Provisions and are provided without 56 warranty as described in the Simplified BSD License. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with 63 respect to this document. 65 Abstract 67 This document introduces the dynamic creation, modification and 68 optimization of services based on the performance monitoring in the 69 Abstraction and Control of Transport Networks (ACTN) architecture. 71 Table of Contents 73 1. Introduction ................................................ 3 74 2. Use Cases and Requirements for Dynamic Service Control based on 75 Performance Monitoring ......................................... 4 76 2.1. Dynamic Service Control based on Traffic Monitoring...... 4 77 2.2. Dynamic Service Control based on SLA monitoring.......... 4 78 3. Workflows of ACTN Control Modules............................ 5 79 3.1. Workflows for Traffic Monitoring based Dynamic Service 80 Control ..................................................... 5 81 3.2. Workflows for SLA monitoring based Dynamic Service control6 82 4. Requirement for ACTN Interface............................... 8 83 4.1. Interface Requirements for Dynamic Service Control Based on 84 Traffic Monitoring .......................................... 8 85 4.2. Interface Requirements of Dynamic Service Control based on 86 SLA monitoring .............................................. 9 87 4.3. Discussion ............................................ 10 88 5. Security Considerations..................................... 10 89 6. IANA Considerations ........................................ 10 90 7. References ................................................. 10 91 7.1. Informative References................................. 10 93 1. Introduction 95 The rapid growth of Internet traffic and the emerging applications 96 such as cloud computing, datacenter interconnection, IP and optical 97 integration, LTE backhauling, are driving the transport network to 98 provide dynamic service provisioning based on the customer 99 requirement and high quality services with guaranteed performance. 101 For datacenter interconnection services, IP network transit links, 102 LTE backhauling services or some business customer services, the 103 traffic vary over time. However, traditional optical network could 104 only provide connection based on the maximum bandwidth needed. Based 105 on flow traffic monitoring, it is possible to adjust the connection 106 bandwidth according to the real bandwidth needed, create new 107 connections or increase bandwidth when network traffic exceeds some 108 certain threshold or reduce connection bandwidth when traffic drops 109 down, thus helping the customers to save cost. 111 On the other hand, customers have different SLA requirements. Some 112 customers such as financial service companies need ultra-low-latency 113 transmission, some other customers has strict requirements on bit 114 error rate (BER). In order to provide high quality services 115 according to customer SLA, network provider needs to measure the 116 service performance, and dynamically provision and optimize services 117 based on the performance monitoring result. 119 The optical transport networks support various performance 120 monitoring mechanisms, such as traffic flow statistics, packet 121 delay, delay variation, throughput and packet-loss rate for MPLS-TP 122 and packet OTN networks, BER, FEC error correction counters for OTN 123 and DWDM networks, etc. These mechanisms can be used to support 124 dynamic service control based on performance monitoring. 126 The Abstraction and Control of Transport Networks (ACTN) described 127 in [ACTN-FWK] provides a centralized control architecture and open 128 interfaces that can transmit the customer requirements and policies 129 to the network, and provide customers with the network status to 130 make a decision. This draft mainly discusses the use cases and 131 requirements of dynamic service control based on performance 132 monitoring in ACTN architecture, the requirements for southbound and 133 northbound interface are also discussed. 135 2. Use Cases and Requirements for Dynamic Service Control based on 136 Performance Monitoring 138 2.1. Dynamic Service Control based on Traffic Monitoring 140 For LTE backhauling based on MPLS-TP packet transport networks(PTN) 141 or packet OTN, it is required that real time or semi-real time 142 traffic monitoring of the network should be conducted so as to 143 resize or optimize traffic and do load balance. In IP and optical 144 network integration scenario, the optical network can bypass IP 145 transit traffic as far as the transit traffic bandwidth is large 146 enough to occupy the granularity of an ODUk. Network traffic 147 monitoring is important to facilitate automatic discovery of the 148 imbalance of network traffic, and initiate the network optimization, 149 thus helping the network operator or the virtual network service 150 provider to use the network more efficiently and save CAPEX/OPEX. 152 For datacenter interconnection or enterprise leased line services, 153 the traffic may vary over time and the customer want to pay for the 154 bandwidth they really used. Therefore, it is important to provide 155 some mechanism to monitor the network traffic, adjust and optimize 156 the services dynamically to help the customers save expenses. 158 In order to support these scenarios, the customers or client layer 159 network controllers need to send traffic monitoring and control 160 policies to the network, while the transport network should report 161 the traffic monitoring results and dynamically control and adjust 162 network connections based on the traffic optimization policy. The 163 service adjustment or network optimization operations normally 164 should be initiated with the decision of the customer. 166 2.2. Dynamic Service Control based on SLA monitoring 168 Customer services have various SLA requirements, such as service 169 availability, latency, latency jitter, packet loss rate, BER, etc. 170 The transport network can satisfy service availability and BER 171 requirements by providing different protection and restoration 172 mechanisms. However, for other performance parameters, there are no 173 such mechanisms. 175 In order to provide high quality services according to customer SLA, 176 one possible solution is to measure the service SLA related 177 performance parameters, and dynamically provision and optimize 178 services based on the performance monitoring results. 180 When the network performance deterioration that violates the SLA is 181 detected, service optimization operations such as service rerouting, 182 creation of new connections could be automatically started. 184 In order to support this requirement, the customer should be able to 185 send its SLA information to the network, and the transport network 186 should determine which performance parameters need to be monitored 187 and the strategy of service optimization. When the service 188 performance degradation is detected, the transport network can 189 notify the customer and immediately start the service optimization 190 procedure, so as to reduce the impact on the service. 192 3. Workflows of ACTN Control Modules 194 In the ACTN architecture [ACTN-FWK], centralized controllers 195 including Physical Network Controller (PNC), Virtual Network 196 Controller (VNC), customer controller, and the interfaces between 197 them have been defined. 199 For different use cases and scenarios the workflows across the 200 customer controller, VNC and PNC are different. 202 3.1. Workflows for Traffic Monitoring based Dynamic Service Control 204 Figure 1 shows the workflows for dynamic service control based on 205 traffic monitoring. 207 In order to realize dynamic service creation, adjustment and 208 optimization based on traffic monitoring, the customer controller 209 should send traffic monitoring and traffic optimization strategies 210 to Virtual Network Controller (VNC). VNC sends the corresponding 211 path traffic monitoring request to PNC. Traffic monitoring 212 parameters and monitoring cycle need to be carried in this request. 214 PNC gets the traffic monitoring results from the underlying physical 215 networks, then reports to VNC. According to the traffic optimization 216 strategy obtained from the customer controller, VNC determines 217 whether the service needs to be adjusted, or a new connection should 218 be created. If it needs to, then VNC send the traffic monitoring 219 results to the customer controller, indicating that the service 220 needs adjustment. 222 Customer controller confirms whether the service can be optimized, 223 then sends a service adjustment request to VNC. VNC will convert it 224 into path modification or creation request, and send it to PNC to 225 complete the service optimization. Then, PNC returns the 226 optimization results to VNC, and VNC passes the results to the 227 customer controller. 229 +------------------------------------------------+ 230 | Customer +-----------------------------+ | 231 | Controller | Dynamic Service Control APP | | 232 | +-----------------------------+ | 233 +------------------------------------------------+ 234 1.Traffic| /|\4.Traffic | /|\ 235 Monitor& | | Monitor | | 8.Traffic 236 Optimize | | Result 5.Service | | modify & 237 Policy | | modify& | | optimize 238 \|/ | optimize Req.\|/ | result 239 +------------------------------------------------+ 240 | Virtual +-------------------------------+ | 241 | Network |Dynamic Service Control Agent | | 242 | Controller +-------------------------------+ | 243 | +---------------+ +-------------------+ | 244 | | Flow Optimize | | vConnection Agent | | 245 | +---------------+ +-------------------+ | 246 +------------------------------------------------+ 247 2. Path | /|\3.Traffic | | 248 Monitor | | Monitor | |7.Path 249 Request | | Result 6.Path | | modify & 250 | | modify& | | optimize 251 \|/ | optimize Req.\|/ | result 252 +-----------------------------------------------+ 253 | Physical +----------------------+ | 254 | Network | Network Provisioning | | 255 | Controller +----------------------+ | 256 | +----------------------+ | 257 | | Network Monitoring | | 258 | +----------------------+ | 259 +-----------------------------------------------+ 260 Figure 1 Workflows for dynamic service control based on traffic 261 monitoring 263 3.2. Workflows for SLA monitoring based Dynamic Service control 265 Figure 2 shows the workflows for dynamic service control based on 266 SLA related performance monitoring. 268 Customer controller sends the customer service SLA information and 269 the performance based optimization strategy to VNC. 271 VNC will convert the SLA information to path performance monitoring 272 request, which carries the performance monitoring parameters such as 273 delay, jitter, packet loss, bit error rate and monitoring cycle, and 274 then send it to the PNC. 276 PNC starts the performance monitoring in the underlying physical 277 networks, collects the results of related path, and reports to VNC. 278 VNC determines whether the relevant performance parameters can 279 satisfy the SLA agreements. If the performance degradation seriously 280 influences the service, such as service packet delay exceeds the 281 performance threshold, VNC will immediately start the optimization 282 and adjustment. Then the performance monitoring results as well as 283 the optimizing or adjusting results will be send to the customer 284 controller. 286 +------------------------------------------------+ 287 | Customer +-----------------------------+ | 288 | Controller | Dynamic Service Control APP | | 289 | +-----------------------------+ | 290 +------------------------------------------------+ 291 1. SLA& | /|\6.SLA | 292 Optimize | | Monitor, modify & | 293 Policy | | Optimize | 294 | | Result | 7.Ack 295 \|/ | \|/ 296 +------------------------------------------------+ 297 | Virtual +-------------------------------+ | 298 | Network |Dynamic Service Control Agent | | 299 | Controller +-------------------------------+ | 300 | +---------------+ +-------------------+ | 301 | | Flow Optimize | | vConnection Agent | | 302 | +---------------+ +-------------------+ | 303 +------------------------------------------------+ 304 2. Path | /|\3.SLA | /|\ 305 Monitor | | Monitor | |5.Path 306 Request | | Result 4.Path | | Modify & 307 | | Modify& | | Optimize 308 \|/ | Optimize Req.\|/ | Result 309 +------------------------------------------------+ 310 | Physical +----------------------+ | 311 | Network | Network Provisioning | | 312 | Controller +----------------------+ | 313 | +----------------------+ | 314 | | Network Monitoring | | 315 | +----------------------+ | 316 +------------------------------------------------+ 317 Figure 2 Workflows for dynamic service control based on SLA 318 monitoring 320 4. Requirement for ACTN Interface 322 ACTN Interfaces defined [ACTN-FWK] includes the following: 324 o Consumer-VNC Interface (CVI): an interface between a customer 325 controller and a virtual network controller. 327 o VNC-PNC Interface (VPI): an interface between a virtual network 328 controller and a physical network controller. 330 4.1. Interface Requirements for Dynamic Service Control Based on 331 Traffic Monitoring 333 According to the work flow of dynamic service control based on 334 performance monitoring, the information carried in CVI interface 335 mainly relates to the traffic monitoring and control strategy, while 336 the VPI interface mainly relates to transports path related traffic 337 monitoring parameters and results. 339 1. CVI Interface 341 The following information is used by the customer controller to send 342 to VNC through the CVI interface. 344 o Customer service performance monitoring strategy, including the 345 traffic monitoring object (the service need to be monitored), 346 monitoring parameters (e.g., transmitted and received bytes per 347 unit time), traffic monitoring cycle (e.g., 15 minutes, 24 hours), 348 threshold of traffic monitoring (e.g., high and low threshold), 349 etc. 351 o Customer service optimization strategy, such as enabling service 352 creation or modification when traffic exceeds the threshold. 354 The following information is used for VNC to send to the customer 355 controller through VPI interface. 357 o Traffic monitoring results, to indicate if the traffic exceeds 358 the bandwidth threshold. 360 2. VPI Interface 362 The following parameters are used for VNC to send to PNC. 364 o Traffic monitoring parameters, monitoring object, monitoring cycle, 365 performance threshold. 367 The following information is used for PNC to send to VNC. 369 o Traffic monitoring results. 371 4.2. Interface Requirements of Dynamic Service Control based on SLA 372 monitoring 374 According to the work flow of dynamic service control based on SLA 375 monitoring, the information in VCI interface mainly contains the SLA 376 related information and measurement strategy, while the VPI 377 interface mainly transports path related performance monitoring 378 parameters and results. 380 1. CVI Interface 382 The following information is used by the customer controller to send 383 to the VNC through CVI interface. 385 o SLA related performance requirement information, including the 386 required quality of service parameters (e.g., BER, delay, delay 387 jitter, packet loss rate, throughput, etc.). 389 o Service optimization strategy, including the service performance 390 degradation thresholds and the consequent operations that are 391 allowed (e.g., rerouting). 393 The following information is used by the customer controller to send 394 to VNC. 396 o Monitoring results of service performance, including performance 397 monitoring parameters, and the services that have been influenced. 399 o Service optimization results based on performance. 401 2. VPI Interface 403 The following information is used by VNC to send to PNC. 405 o The path performance monitoring request parameters, monitoring 406 cycle and threshold. 408 The following information is used for PNC sending to VNC. 410 o Path performance monitoring results. 412 4.3. Discussion 414 Performance monitoring in a large scale network could generate a 415 huge amount of performance information. Therefore, the appropriate 416 way to deliver the information in CVI and VPI interfaces should be 417 carefully considered. 419 5. Security Considerations 421 This document raises no new security issues. 423 6. IANA Considerations 425 No new IANA considerations are raised by this document. 427 7. References 429 7.1. Informative References 431 [ACTN-FWK] Daniele C., Luyuan Fang, Yong Lee and Diego Lopez, 432 "Framework for Abstraction and Control of Transport 433 Networks",draft-ceccarelli-actn-framework-00. 435 Authors' Address 437 Yunbin Xu 438 China Academy of Telecom Research 439 NO.52 Huayuan Beilu, Haidian District, Beijing, China 440 Email: xuyunbin@catr.cn 442 Guoying Zhang 443 China Academy of Telecom Research 444 NO.52 Huayuan Beilu, Haidian District, Beijing, China 445 Email: zhangguoying@catr.cn 447 Weiqiang Cheng 448 China Mobile 449 No.32 Xuanwumen West Street, Xicheng District, Beijing, China 450 Email:chengweiqiang@chinamobile.com 452 Haomian Zheng 453 Huawei Technologies 454 F3-1-B R&D Center, Bantian, Longgang District Shenzhen, China 455 Email: zhenghaomian@huawei.com