idnits 2.17.1 draft-xu-actn-perf-dynamic-service-control-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 Abstract section. ** There are 12 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 4, 2014) is 3585 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-02 Summary: 2 errors (**), 0 flaws (~~), 2 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: January2015 5 Guoying Zhang 6 CATR 8 Weiqiang Cheng 9 CMCC 11 Haomian zheng 12 Huawei 14 July 4, 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-01.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." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html 40 This Internet-Draft will expire on January 4, 2015. 42 Copyright Notice 44 Copyright (c) 2014 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info)in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with 52 respect to this document. Code Components extracted from this 53 document must include Simplified BSD License text as described in 54 Section 4.e of the Trust Legal Provisions and are provided without 55 warranty as described in the Simplified BSD License. 57 This document is subject to BCP 78 and the IETF Trust's Legal 58 Provisions Relating to IETF Documents 59 (http://trustee.ietf.org/license-info) in effect on the date of 60 publication of this document. Please review these documents 61 carefully, as they describe your rights and restrictions with 62 respect to this document. 63 Abstract 65 This document introduces the dynamic creation, modification and 66 optimization of services based on the performance monitoring in the 67 Abstraction and Control of Transport Networks (ACTN) architecture. 69 Table of Contents 71 1. Introduction...................................................3 72 2. Use Cases and Requirements for Dynamic Service Control based on 73 Performance Monitoring............................................4 74 2.1. Dynamic Service Control based on Traffic Monitoring.......4 75 2.2. Dynamic Service Control based on SLA monitoring...........4 76 3. Workflows of ACTN Control Modules..............................5 77 3.1. Workflows for Traffic Monitoring based Dynamic Service 78 Control........................................................5 79 3.2. Workflows for SLA monitoring based Dynamic Service control6 80 4. Requirement for ACTN Interface.................................8 81 4.1. Interface Requirements for Dynamic Service Control Based on 82 Traffic Monitoring.............................................8 83 4.2. Interface Requirements of Dynamic Service Control based on 84 SLA monitoring.................................................9 85 4.3. Discussion...............................................10 86 5. Security Considerations.......................................10 87 6. IANA Considerations...........................................10 88 7. References....................................................10 89 7.1. Informative References...................................10 91 1. Introduction 93 The rapid growth of Internet traffic and the emerging applications 94 such as cloud computing, datacenter interconnection, IP and optical 95 integration, LTE backhauling, are driving the transport network to 96 provide dynamic service provisioning based on the customer 97 requirement and high quality services with guaranteed performance. 99 For datacenter interconnection services, IP network transit links, 100 LTE backhauling services or some business customer services, the 101 traffic vary over time. However, traditional optical network could 102 only provide connection based on the maximum bandwidth needed. Based 103 on flow traffic monitoring, it is possible to adjust the connection 104 bandwidth according to the real bandwidth needed, create new 105 connections or increase bandwidth when network traffic exceeds some 106 certain threshold or reduce connection bandwidth when traffic drops 107 down, thus helping the customers to save cost. 109 On the other hand, customers have different SLA requirements. Some 110 customers such as financial service companies need ultra-low-latency 111 transmission, some other customers has strict requirements on bit 112 error rate (BER). In order to provide high quality services 113 according to customer SLA, network provider needs to measure the 114 service performance, and dynamically provision and optimize services 115 based on the performance monitoring result. 117 The optical transport networks support various performance 118 monitoring mechanisms, such as traffic flow statistics, packet 119 delay, delay variation, throughput and packet-loss rate for MPLS-TP 120 and packet OTN networks, BER, FEC error correction counters for OTN 121 and DWDM networks, etc. These mechanisms can be used to support 122 dynamic service control based on performance monitoring. 124 The Abstraction and Control of Transport Networks (ACTN) described 125 in [ACTN-FWK] provides a centralized control architecture and open 126 interfaces that can transmit the customer requirements and policies 127 to the network, and provide customers with the network status to 128 make a decision. This draft mainly discusses the use cases and 129 requirements of dynamic service control based on performance 130 monitoring in ACTN architecture, the requirements for southbound and 131 northbound interface are also discussed. 133 2. Use Cases and Requirements for Dynamic Service Control based on 134 Performance Monitoring 136 2.1. Dynamic Service Control based on Traffic Monitoring 138 For LTE backhauling based on MPLS-TP packet transport networks(PTN) 139 or packet OTN, it is required that real time or semi-real time 140 traffic monitoring of the network should be conducted so as to 141 resize or optimize traffic and do load balance. In IP and optical 142 network integration scenario, the optical network can bypass IP 143 transit traffic as far as the transit traffic bandwidth is large 144 enough to occupy the granularity of an ODUk. Network traffic 145 monitoring is important to facilitate automatic discovery of the 146 imbalance of network traffic, and initiate the network optimization, 147 thus helping the network operator or the virtual network service 148 provider to use the network more efficiently and save CAPEX/OPEX. 149 For datacenter interconnection or enterprise leased line services, 150 the traffic may vary over time and the customer want to pay for the 151 bandwidth they really used. Therefore, it is important to provide 152 some mechanism to monitor the network traffic, adjust and optimize 153 the services dynamically to help the customers save expenses. 155 In order to support these scenarios, the customers or client layer 156 network controllers need to send traffic monitoring and control 157 policies to the network, while the transport network should report 158 the traffic monitoring results and dynamically control and adjust 159 network connections based on the traffic optimization policy. The 160 service adjustment or network optimization operations normally 161 should be initiated with the decision of the customer. 163 2.2. Dynamic Service Control based on SLA monitoring 165 Customer services have various SLA requirements, such as service 166 availability, latency, latency jitter, packet loss rate, BER, etc. 167 The transport network can satisfy service availability and BER 168 requirements by providing different protection and restoration 169 mechanisms. However, for other performance parameters, there are no 170 such mechanisms. 172 In order to provide high quality services according to customer SLA, 173 one possible solution is to measure the service SLA related 174 performance parameters, and dynamically provision and optimize 175 services based on the performance monitoring results. 177 When the network performance deterioration that violates the SLA is 178 detected, service optimization operations such as service rerouting, 179 creation of new connections could be automatically started. 181 In order to support this requirement, the customer should be able to 182 send its SLA information to the network, and the transport network 183 should determine which performance parameters need to be monitored 184 and the strategy of service optimization. When the service 185 performance degradation is detected, the transport network can 186 notify the customer and immediately start the service optimization 187 procedure, so as to reduce the impact on the service. 189 3. Workflows of ACTN Control Modules 191 In the ACTN architecture [ACTN-FWK], centralized controllers 192 including Physical Network Controller (PNC), Virtual Network 193 Controller (VNC), customer controller, and the interfaces between 194 them have been defined. 196 For different use cases and scenarios, the workflows across the 197 customer controller, VNC and PNC are different. 199 3.1. Workflows for Traffic Monitoring based Dynamic Service Control 201 Figure 1 shows the workflows for dynamic service control based on 202 traffic monitoring. 204 In order to realize dynamic service creation, adjustment and 205 optimization based on traffic monitoring, the customer controller 206 should send traffic monitoring and traffic optimization strategies 207 to Virtual Network Controller (VNC). VNC sends the corresponding 208 path traffic monitoring request to PNC. Traffic monitoring 209 parameters and monitoring cycle need to be carried in this request. 211 PNC gets the traffic monitoring results from the underlying physical 212 networks, translates the monitoring results of the physical topology 213 to the performance information of the abstract topology, and then 214 reports to VNC. According to the traffic optimization strategy 215 obtained from the customer controller, VNC determines whether the 216 service needs to be adjusted, or a new connection should be created. 217 If it needs to, then VNC send the traffic monitoring results to the 218 customer controller, indicating that the service needs adjustment. 220 Customer controller confirms whether the service can be optimized, 221 then sends a service adjustment request to VNC. VNC will convert it 222 into path modification or creation request, and send it to PNC to 223 complete the service optimization. Then, PNC returns the 224 optimization results to VNC, and VNC passes the results to the 225 customer controller. 227 +------------------------------------------------+ 228 | Customer +-----------------------------+ | 229 | Controller | Dynamic Service Control APP | | 230 | +-----------------------------+ | 231 +------------------------------------------------+ 232 1.Traffic| /|\4.Traffic | /|\ 233 Monitor& | | Monitor | | 8.Traffic 234 Optimize | | Result 5.Service | | modify & 235 Policy | | modify& | | optimize 236 \|/ | optimize Req.\|/ | result 237 +------------------------------------------------+ 238 | Virtual +-------------------------------+ | 239 | Network |Dynamic Service Control Agent | | 240 | Controller +-------------------------------+ | 241 | +---------------+ +-------------------+ | 242 | | Flow Optimize | | vConnection Agent | | 243 | +---------------+ +-------------------+ | 244 +------------------------------------------------+ 245 2. Path | /|\3.Traffic | | 246 Monitor | | Monitor | |7.Path 247 Request | | Result 6.Path | | modify & 248 | | modify& | | optimize 249 \|/ | optimize Req.\|/ | result 250 +--------------------------------------------------------------+ 251 | Physical +----------------------+ +----------------------+ | 252 | Network | Network Provisioning | |Abstract Topology Gen.| | 253 | Controller +----------------------+ +----------------------+ | 254 | +------------------+ +--------------------+ | 255 | |Network Monitoring| |Physical Topology DB| | 256 | +------------------+ +--------------------+ | 257 +--------------------------------------------------------------+ 259 Figure 1 Workflows for dynamic service control based on traffic 260 monitoring 262 3.2. Workflows for SLA monitoring based Dynamic Service control 264 Figure 2 shows the workflows for dynamic service control based on 265 SLA related performance monitoring. 267 Customer controller sends the customer service SLA information and 268 the performance based optimization strategy to VNC. 270 VNC will convert the SLA information to path performance monitoring 271 request, which carries the performance monitoring parameters such as 272 delay, jitter, packet loss, bit error rate and monitoring cycle, and 273 then send it to the PNC. 275 PNC starts the performance monitoring in the underlying physical 276 networks, collects the results of related path, translates the 277 performance results of the physical topology to the performance 278 information of the abstract topology, and reports to VNC. VNC 279 determines whether the relevant performance parameters can satisfy 280 the SLA agreements. If the performance degradation seriously 281 influences the service, such as service packet delay exceeds the 282 performance threshold, VNC will immediately start the optimization 283 and adjustment. Then the performance monitoring results as well as 284 the optimizing or adjusting results will be send to the customer 285 controller. 287 +------------------------------------------------+ 288 | Customer +-----------------------------+ | 289 | Controller | Dynamic Service Control APP | | 290 | +-----------------------------+ | 291 +------------------------------------------------+ 292 1. SLA& | /|\6.SLA | 293 Optimize | | Monitor, modify & | 294 Policy | | Optimize | 295 | | Result | 7.Ack 296 \|/ | \|/ 297 +------------------------------------------------+ 298 | Virtual +-------------------------------+ | 299 | Network |Dynamic Service Control Agent | | 300 | Controller +-------------------------------+ | 301 | +---------------+ +-------------------+ | 302 | | Flow Optimize | | vConnection Agent | | 303 | +---------------+ +-------------------+ | 304 +------------------------------------------------+ 305 2. Path | /|\3.SLA | /|\ 306 Monitor | | Monitor | |5.Path 307 Request | | Result 4.Path | | Modify & 308 | | Modify& | | Optimize 309 \|/ | Optimize Req.\|/ | Result 310 +--------------------------------------------------------------+ 311 | Physical +----------------------+ +----------------------+ | 312 | Network | Network Provisioning | |Abstract Topology Gen.| | 313 | Controller +----------------------+ +----------------------+ | 314 | +------------------+ +--------------------+ | 315 | |Network Monitoring| |Physical Topology DB| | 316 | +------------------+ +--------------------+ | 317 +--------------------------------------------------------------+ 318 Figure 2 Workflows for dynamic service control based on SLA 319 monitoring 321 4. Requirement for ACTN Interface 323 ACTN Interfaces defined [ACTN-FWK] includes the following: 325 o Consumer-VNC Interface (CVI): an interface between a customer 326 controller and a virtual network controller. 328 o VNC-PNC Interface (VPI): an interface between a virtual network 329 controller and a physical network controller. 331 4.1. Interface Requirements for Dynamic Service Control Based on 332 Traffic Monitoring 334 According to the work flow of dynamic service control based on 335 performance monitoring, the information carried in CVI interface 336 mainly relates to the traffic monitoring and control strategy, while 337 the VPI interface mainly relates to transports path related traffic 338 monitoring parameters and results. 340 1. CVI Interface 342 The following information is used by the customer controller to send 343 to VNC through the CVI interface. 345 o Customer service performance monitoring strategy, including the 346 traffic monitoring object (the service need to be monitored), 347 monitoring parameters (e.g., transmitted and received bytes per 348 unit time), traffic monitoring cycle (e.g., 15 minutes, 24 hours), 349 threshold of traffic monitoring (e.g., high and low threshold), 350 etc. 352 o Customer service optimization strategy, such as enabling service 353 creation or modification when traffic exceeds the threshold. 355 The following information is used for VNC to send to the customer 356 controller through VPI interface. 358 o Traffic monitoring results, to indicate if the traffic exceeds 359 the bandwidth threshold. 361 2. VPI Interface 363 The following parameters are used for VNC to send to PNC. 365 o Traffic monitoring parameters, monitoring object, monitoring cycle, 366 performance threshold. 368 The following information is used for PNC to send to VNC. 370 o Traffic monitoring results. These results must be translated from 371 the physical topology to abstract topology by the Abstract 372 Topology Generalization module firstly. 374 4.2. Interface Requirements of Dynamic Service Control based on SLA 375 monitoring 376 According to the work flow of dynamic service control based on SLA 377 monitoring, the information in VCI interface mainly contains the SLA 378 related information and measurement strategy, while the VPI 379 interface mainly transports path related performance monitoring 380 parameters and results. 382 1. CVI Interface 384 The following information is used by the customer controller to send 385 to the VNC through CVI interface. 387 o SLA related performance requirement information, including the 388 required quality of service parameters (e.g., BER, delay, delay 389 jitter, packet loss rate, throughput, etc.). 391 o Service optimization strategy, including the service performance 392 degradation thresholds and the consequent operations that are 393 allowed (e.g., rerouting). 395 The following information is used by the customer controller to send 396 to VNC. 397 o Monitoring results of service performance, including performance 398 monitoring parameters, and the services that have been influenced. 400 o Service optimization results based on performance. 402 2. VPI Interface 404 The following information is used by VNC to send to PNC. 406 o The path performance monitoring request parameters, monitoring 407 cycle and threshold. 409 The following information is used for PNC sending to VNC. 411 o Path performance monitoring results. 413 4.3. Discussion 415 Performance monitoring in a large scale network could generate a 416 huge amount of performance information. Therefore, the appropriate 417 way to deliver the information in CVI and VPI interfaces should be 418 carefully considered. 420 5. Security Considerations 422 This document raises no new security issues. 424 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-02. 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 Communication Company 449 Email:chengweiqiang@chinamobile.com 451 Haomian Zheng 452 Huawei Technologies 453 F3-1-B R&D Center, Bantian, Longgang District Shenzhen, China 454 Email: zhenghaomian@huawei.com