idnits 2.17.1 draft-xu-actn-perf-dynamic-service-control-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a Notice of Compliance with BCP 78 and BCP 79 according to IETF Trust Provisions of 28 Dec 2009, Section 6.a or Provisions of 12 Sep 2009, Section 6.a. 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 117 has weird spacing: '...itoring mecha...' == Line 411 has weird spacing: '...rmation used ...' == Line 417 has weird spacing: '...rmation of PN...' -- The document date (October 25, 2014) is 3470 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-03 Summary: 1 error (**), 0 flaws (~~), 5 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: April, 25, 2015 5 Guoying Zhang 6 CATR 8 Weiqiang Cheng 9 CMCC 11 Haomian Zheng 12 Huawei 14 October 25, 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-02.txt 20 Status of this Memo 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six 28 months and may be updated, replaced, or obsoleted by other documents 29 at any time. It is inappropriate to use Internet-Drafts as 30 reference material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed 33 at http://www.ietf.org/ietf/1id-abstracts.txt 35 The list of Internet-Draft Shadow Directories can be accessed 36 at http://www.ietf.org/shadow.html 38 This Internet-Draft will expire on April 25, 2015. 40 Copyright Notice 42 Copyright (c) 2014 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info)in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with 50 respect to this document. Code Components extracted from this 51 document must include Simplified BSD License text as described in 52 Section 4.e of the Trust Legal Provisions and are provided without 53 warranty as described in the Simplified BSD License. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with 60 respect to this document. 62 Abstract 64 This document introduces the dynamic creation, modification and 65 optimization of services based on the performance monitoring in the 66 Abstraction and Control of Transport Networks (ACTN) architecture. 68 Table of Contents 70 1. Introduction ....................................... 3 71 2. Use Cases and Requirements for Dynamic Service Control based on 72 Performance Monitoring .................................. 3 73 2.1. Dynamic Service Control based on Traffic Monitoring..... 3 74 2.2. Dynamic Service Control based on SLA monitoring........ 4 75 3. Workflows of ACTN Control Modules ....................... 5 76 3.1. Workflows for Traffic Monitoring based Dynamic Service 77 Control ........................................... 5 78 3.2. Workflows for SLA monitoring based Dynamic Service control6 79 4. Requirement for ACTN Interface ......................... 8 80 4.1. Interface Requirements for Dynamic Service Control Based on 81 Traffic Monitoring ................................... 8 82 4.2. Interface Requirements of Dynamic Service Control based on 83 SLA monitoring ...................................... 9 84 4.3. Discussion .................................... 10 85 5. Security Considerations .............................. 10 86 6. IANA Considerations ................................. 10 87 7. References ........................................ 10 88 7.1. Informative References........................... 10 90 1. Introduction 92 The rapid growth of Internet traffic and the emerging applications 93 such as cloud computing, datacenter interconnection, IP and optical 94 integration, LTE backhauling, are driving the transport network to 95 provide dynamic service provisioning based on the customer 96 requirement and high quality services with guaranteed performance. 98 For datacenter interconnection services, IP network transit links, 99 LTE backhauling services or some business customer services, the 100 traffic vary over time. However, traditional optical network could 101 only provide connection based on the maximum bandwidth needed. Based 102 on flow traffic monitoring, it is possible to adjust the connection 103 bandwidth according to the real bandwidth needed, create new 104 connections or increase bandwidth when network traffic exceeds some 105 certain threshold or reduce connection bandwidth when traffic drops 106 down, thus helping the customers to save cost. 108 On the other hand, customers have different SLA requirements. Some 109 customers such as financial service companies need ultra-low-latency 110 transmission, some other customers has strict requirements on bit 111 error rate (BER). In order to provide high quality services 112 according to customer SLA, network provider needs to measure the 113 service performance, and dynamically provision and optimize services 114 based on the performance monitoring result. 116 The optical transport networks support various performance 117 monitoring mechanisms, such as traffic flow statistics, packet 118 delay, delay variation, throughput and packet-loss rate for MPLS-TP 119 and packet OTN networks, BER, FEC error correction counters for OTN 120 and DWDM networks, etc. These mechanisms can be used to support 121 dynamic service control based on performance monitoring. 123 The Abstraction and Control of Transport Networks (ACTN) described 124 in [ACTN-FWK] provides a centralized control architecture and open 125 interfaces that can transmit the customer requirements and policies 126 to the network, and provide customers with the network status to 127 make a decision. This draft mainly discusses the use cases and 128 requirements of dynamic service control based on performance 129 monitoring in ACTN architecture, the requirements for southbound and 130 northbound interface are also discussed. 132 2. Use Cases and Requirements for Dynamic Service Control based on 133 Performance Monitoring 135 2.1. Dynamic Service Control based on Traffic Monitoring 137 For LTE backhauling based on MPLS-TP packet transport networks(PTN) 138 or packet OTN, it is required that real time or semi-real time 139 traffic monitoring of the network should be conducted so as to 140 resize or optimize traffic and do load balance. In IP and optical 141 network integration scenario, the optical network can bypass IP 142 transit traffic as far as the transit traffic bandwidth is large 143 enough to occupy the granularity of an ODUk. Network traffic 144 monitoring is important to facilitate automatic discovery of the 145 imbalance of network traffic, and initiate the network optimization, 146 thus helping the network operator or the virtual network service 147 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 customized 173 SLAs, one possible solution is to measure the service SLA related 174 performance parameters, and dynamically optimize service 175 provisioning 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 Network Controller, and interfaces 194 between them have been defined. 196 For different use cases and scenarios the workflows across the 197 Customer Network 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 Network 206 Controller should send traffic monitoring and traffic optimization 207 strategies to Virtual Network Controller (VNC). VNC sends the 208 corresponding path traffic monitoring request to PNC. Traffic 209 monitoring parameters and monitoring cycle need to be carried in 210 this request. 212 PNC gets the traffic monitoring results from the underlying physical 213 networks, translates the monitoring results of the physical topology 214 to the performance information of the abstract topology, and then 215 reports to VNC. According to the traffic optimization strategy 216 obtained from the Customer Network Controller, VNC determines the 217 optimization procedure, which may include but not limited to 218 adjusting an existing service, or creating a new connection for load 219 balance. If it needs to, then VNC send the traffic monitoring 220 results to the Customer Network Controller, indicating that the 221 services that need adjustment. 223 Customer Network Controller firstly confirms whether the service can 224 be optimized, and then sends a service adjustment request to VNC. 225 VNC will convert it into path modification or creation request, and 226 send it to PNC to complete the service optimization. After that, PNC 227 returns the optimization results to VNC, and VNC passes the results 228 to the Customer Network Controller. 230 +------------------------------------------------+ 231 | Customer +-----------------------------+ | 232 | Network | Dynamic Service Control APP | | 233 | Controller +-----------------------------+ | 234 +------------------------------------------------+ 235 1.Traffic| /|\4.Traffic | /|\ 236 Monitor& | | Monitor | | 8.Traffic 237 Optimize | | Result 5.Service | | modify & 238 Policy | | modify& | | optimize 239 \|/ | optimize Req.\|/ | result 240 +------------------------------------------------+ 241 | Virtual +-------------------------------+ | 242 | Network |Dynamic Service Control Agent | | 243 | Controller +-------------------------------+ | 244 | +---------------+ +-------------------+ | 245 | | Flow Optimize | | vConnection Agent | | 246 | +---------------+ +-------------------+ | 247 +------------------------------------------------+ 248 2. Path | /|\3.Traffic | | 249 Monitor | | Monitor | |7.Path 250 Request | | Result 6.Path | | modify & 251 | | modify& | | optimize 252 \|/ | optimize Req.\|/ | result 253 +--------------------------------------------------------------+ 254 | Physical +----------------------+ +----------------------+ | 255 | Network | Network Provisioning | |Abstract Topology Gen.| | 256 | Controller +----------------------+ +----------------------+ | 257 | +------------------+ +--------------------+ | 258 | |Network Monitoring| |Physical Topology DB| | 259 | +------------------+ +--------------------+ | 260 +--------------------------------------------------------------+ 262 Figure 1 Workflows for dynamic service control based on traffic 263 monitoring 265 3.2. Workflows for SLA monitoring based Dynamic Service control 267 Figure 2 shows the workflows for dynamic service control based on 268 SLA related performance monitoring. 270 Customer Network Controller sends the customer service SLA 271 information and the performance based optimization strategy to VNC. 273 VNC will convert the SLA information to path performance monitoring 274 request, which carries the performance monitoring parameters such as 275 delay, jitter, packet loss, bit error rate and monitoring cycle, and 276 then send it to the PNC. 278 PNC starts the performance monitoring in the underlying physical 279 networks, collects the results of related path, translates the 280 performance results of the physical topology to the performance 281 information of the abstract topology, and reports to VNC. VNC 282 determines whether the relevant performance parameters can satisfy 283 the SLA agreements. If the performance degradation seriously 284 influences the service, for example the service packet delay exceeds 285 the performance threshold, the VNC will immediately start the 286 optimization procedure for adjustment. Then the performance 287 monitoring results as well as the optimizing or adjusting results 288 will be send to the Customer Network Controller. 290 +------------------------------------------------+ 291 | Customer +-----------------------------+ | 292 | Controller | Dynamic Service Control APP | | 293 | +-----------------------------+ | 294 +------------------------------------------------+ 295 1. SLA& | /|\6.SLA | 296 Optimize | | Monitor, modify & | 297 Policy | | Optimize | 298 | | Result | 7.Ack 299 \|/ | \|/ 300 +------------------------------------------------+ 301 | Virtual +-------------------------------+ | 302 | Network |Dynamic Service Control Agent | | 303 | Controller +-------------------------------+ | 304 | +---------------+ +-------------------+ | 305 | | Flow Optimize | | vConnection Agent | | 306 | +---------------+ +-------------------+ | 307 +------------------------------------------------+ 308 2. Path | /|\3.SLA | /|\ 309 Monitor | | Monitor | |5.Path 310 Request | | Result 4.Path | | Modify & 311 | | Modify& | | Optimize 312 \|/ | Optimize Req.\|/ | Result 313 +--------------------------------------------------------------+ 314 | Physical +----------------------+ +----------------------+ | 315 | Network | Network Provisioning | |Abstract Topology Gen.| | 316 | Controller +----------------------+ +----------------------+ | 317 | +------------------+ +--------------------+ | 318 | |Network Monitoring| |Physical Topology DB| | 319 | +------------------+ +--------------------+ | 320 +--------------------------------------------------------------+ 321 Figure 2 Workflows for dynamic service control based on SLA 322 monitoring 324 4. Requirement for ACTN Interface 326 ACTN Interfaces defined in [ACTN-FWK] includes the following: 328 o Consumer-VNC Interface (CVI): an interface between a Customer 329 Network Controller and a virtual network controller. 331 o VNC-PNC Interface (VPI): an interface between a virtual network 332 controller and a physical network controller. 334 4.1. Interface Requirements for Dynamic Service Control Based on 335 Traffic Monitoring 337 According to the work flow of dynamic service control based on 338 performance monitoring, the information carried in CVI interface 339 mainly relates to the traffic monitoring and control strategy, while 340 the VPI interface mainly relates to transports path related traffic 341 monitoring parameters and results. 343 1. CVI Interface 345 The following information used by the Customer Network Controller 346 should besent to VNC through the CVI. 348 o Customer service performance monitoring strategy, including the 349 traffic monitoring object (the service need to be monitored), 350 monitoring parameters (e.g., transmitted and received bytes per 351 unit time), traffic monitoring cycle (e.g., 15 minutes, 24 hours), 352 threshold of traffic monitoring (e.g., high and low threshold), 353 etc. 355 o Customer service optimization strategy, such as enabling service 356 creation or modification when traffic exceeds the threshold. 358 The following information used by VNC should be sent to the Customer 359 Network Controller through VPI. 361 o Traffic monitoring results, to indicate if the traffic exceeds 362 the bandwidth threshold. 364 2. VPI Interface 366 The following parameters used by the VNC should be sent to PNC 367 through VPI. 369 o Traffic monitoring parameters, monitoring object, monitoring cycle, 370 performance threshold. 372 The following information used by the PNC should be sent to VNC 373 through VPI. 375 o Traffic monitoring results. These results must be translated from 376 the physical topology to abstract topology by the Abstract 377 Topology Generalization module firstly. 379 4.2. Interface Requirements of Dynamic Service Control based on SLA 380 monitoring 382 According to the work flow of dynamic service control based on SLA 383 monitoring, the information in VCI interface mainly contains the SLA 384 related information and measurement strategy, while the VPI 385 interface mainly transports path related performance monitoring 386 parameters and results. 388 1. CVI Interface 390 The following information used by the Customer Network Controller 391 should be sent to the VNC through CVI. 393 o SLA related performance requirement information, including the 394 required quality of service parameters (e.g., BER, delay, delay 395 jitter, packet loss rate, throughput, etc.). 397 o Service optimization strategy, including the service performance 398 degradation thresholds and the consequent operations that are 399 allowed (e.g., rerouting). 401 The following information is used by the Customer Network Controller 402 to send to VNC through CVI. 404 o Monitoring results of service performance, including performance 405 monitoring parameters, and the services that have been influenced. 407 o Service optimization results based on performance. 409 2. VPI Interface 411 The following information used by VNC should be sent to PNC through 412 VPI. 414 o The path performance monitoring request parameters, monitoring 415 cycle and threshold. 417 The following information of PNC should be sent to VNC via VPI. 419 o Path performance monitoring results. 421 4.3. Discussion 423 Performance monitoring in a large scale network could generate a 424 huge amount of performance information. Therefore, the appropriate 425 way to deliver the information in CVI and VPI interfaces should be 426 carefully considered. 428 5. Security Considerations 430 This document raises no new security issues. 432 6. IANA Considerations 434 No new IANA considerations are raised by this document. 436 7. References 438 7.1. Informative References 440 [ACTN-FWK] Daniele C., Luyuan Fang, Yong Lee and Diego Lopez, 441 "Framework for Abstraction and Control of Transport 442 Networks",draft-ceccarelli-actn-framework-03. 444 Authors' Address 446 Yunbin Xu 447 China Academy of Telecom Research 448 NO.52 Huayuan Beilu, Haidian District, Beijing, China 449 Email: xuyunbin@catr.cn 451 Guoying Zhang 452 China Academy of Telecom Research 453 NO.52 Huayuan Beilu, Haidian District, Beijing, China 454 Email: zhangguoying@catr.cn 456 Weiqiang Cheng 457 China Mobile Communication Company 459 Email:chengweiqiang@chinamobile.com 461 Haomian Zheng 462 Huawei Technologies 463 F3-1-B R&D Center, Bantian, Longgang District Shenzhen, China 464 Email: zhenghaomian@huawei.com