idnits 2.17.1 draft-xu-actn-perf-dynamic-service-control-03.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: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 10 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 3 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 (April 27, 2015) is 3280 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 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: October2015 5 Guoying Zhang 6 CATR 8 Weiqiang Cheng 9 CMCC 11 Haomian zheng 12 Huawei 14 April 27, 2015 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-03.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 at 36 http://www.ietf.org/ietf/1id-abstracts.txt 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html 41 This Internet-Draft will expire on October 27, 2015. 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 66 This document introduces the dynamic creation, modification and 67 optimization of services based on the performance monitoring in the 68 Abstraction and Control of Transport Networks (ACTN) architecture. 70 Table of Contents 72 1. Introduction...................................................3 73 2. Use Cases and Requirements for Dynamic Service Control based on 74 Performance Monitoring............................................3 75 2.1. Dynamic Service Control based on Traffic Monitoring.......3 76 2.2. Dynamic Service Control based on SLA monitoring...........4 77 3. Workflows of ACTN Control Modules..............................5 78 3.1. Workflows for Traffic Monitoring based Dynamic Service 79 Control........................................................5 80 3.2. Workflows for SLA monitoring based Dynamic Service control6 81 4. Requirement for ACTN Interface.................................8 82 4.1. Interface Requirements for Dynamic Service Control Based on 83 Traffic Monitoring.............................................8 84 4.2. Interface Requirements of Dynamic Service Control based on 85 SLA monitoring.................................................9 86 4.3. Discussion................................................9 87 5. Security Considerations.......................................10 88 6. IANA Considerations...........................................10 89 7. References....................................................10 90 7.1. Informative References...................................10 92 1. Introduction 94 The rapid growth of Internet traffic and the emerging applications 95 such as cloud computing, datacenter interconnection, IP and optical 96 integration, LTE backhauling, are driving the transport network to 97 provide dynamic service provisioning based on the customer 98 requirement and high quality services with guaranteed performance. 100 For datacenter interconnection services, IP network transit links, 101 LTE backhauling services or some business customer services, the 102 traffic vary over time. However, traditional optical network could 103 only provide connection based on the maximum bandwidth needed. Based 104 on flow traffic monitoring, it is possible to adjust the connection 105 bandwidth according to the real bandwidth needed, create new 106 connections or increase bandwidth when network traffic exceeds some 107 certain threshold or reduce connection bandwidth when traffic drops 108 down, thus helping the customers to save cost. 110 On the other hand, customers have different SLA requirements. Some 111 customers such as financial service companies need ultra-low-latency 112 transmission, some other customers has strict requirements on bit 113 error rate (BER). In order to provide high quality services 114 according to customer SLA, network provider needs to measure the 115 service performance, and dynamically provision and optimize services 116 based on the performance monitoring result. 118 The optical transport networks support various performance 119 monitoring mechanisms, such as traffic flow statistics, packet 120 delay, delay variation, throughput and packet-loss rate for MPLS-TP 121 and packet OTN networks, BER, FEC error correction counters for OTN 122 and DWDM networks, etc. These mechanisms can be used to support 123 dynamic service control based on performance monitoring. 125 The Abstraction and Control of Transport Networks (ACTN) described 126 in [ACTN-FWK] provides a centralized control architecture and open 127 interfaces that can transmit the customer requirements and policies 128 to the network, and provide customers with the network status to 129 make a decision. This draft mainly discusses the use cases and 130 requirements of dynamic service control based on performance 131 monitoring in ACTN architecture, the requirements for southbound and 132 northbound interface are also discussed. 134 2. Use Cases and Requirements for Dynamic Service Control based on 135 Performance Monitoring 137 2.1. Dynamic Service Control based on Traffic Monitoring 139 For LTE backhauling based on MPLS-TP packet transport networks(PTN) 140 or packet OTN, it is required that real time or semi-real time 141 traffic monitoring of the network should be conducted so as to 142 resize or optimize traffic and do load balance. In IP and optical 143 network integration scenario, the optical network can bypass IP 144 transit traffic as far as the transit traffic bandwidth is large 145 enough to occupy the granularity of an ODUk. Network traffic 146 monitoring is important to facilitate automatic discovery of the 147 imbalance of network traffic, and initiate the network optimization, 148 thus helping the network operator or the virtual network service 149 provider to use the network more efficiently and save CAPEX/OPEX. 151 For datacenter interconnection or enterprise leased line services, 152 the traffic may vary over time and the customer want to pay for the 153 bandwidth they really used. Therefore, it is important to provide 154 some mechanism to monitor the network traffic, adjust and optimize 155 the services dynamically to help the customers save expenses. 156 In order to support these scenarios, the customers or client layer 157 network controllers need to send traffic monitoring and control 158 policies to the network, while the transport network should report 159 the traffic monitoring results and dynamically control and adjust 160 network connections based on the traffic optimization policy. The 161 service adjustment or network optimization operations normally 162 should be initiated with the decision of the customer. 164 2.2. Dynamic Service Control based on SLA monitoring 166 Customer services have various SLA requirements, such as service 167 availability, latency, latency jitter, packet loss rate, BER, etc. 168 The transport network can satisfy service availability and BER 169 requirements by providing different protection and restoration 170 mechanisms. However, for other performance parameters, there are no 171 such mechanisms. 173 In order to provide high quality services according to customer SLA, 174 one possible solution is to measure the service SLA related 175 performance parameters, and dynamically provision and optimize 176 services based on the performance monitoring results. 178 When the network performance deterioration that violates the SLA is 179 detected, service optimization operations such as service rerouting, 180 creation of new connections could be automatically started. 182 In order to support this requirement, the customer should be able to 183 send its SLA information to the network, and the transport network 184 should determine which performance parameters need to be monitored 185 and the strategy of service optimization. When the service 186 performance degradation is detected, the transport network can 187 notify the customer and immediately start the service optimization 188 procedure, so as to reduce the impact on the service. 190 3. Workflows of ACTN Control Modules 192 In the ACTN architecture [ACTN-FWK], centralized controllers 193 including Physical Network Controller (PNC), Multi Domain Service 194 Coordinator (MDSC), Customer Network Controller(CNC), and the 195 interfaces between them have been defined. 197 For different use cases and scenarios, the workflows across the 198 customer controller, MDSC and PNC are different. 200 3.1. Workflows for Traffic Monitoring based Dynamic Service Control 202 Figure 1 shows the workflows for dynamic service control based on 203 traffic monitoring. 205 In order to realize dynamic service creation, adjustment and 206 optimization based on traffic monitoring, the customer controller 207 should send traffic monitoring and traffic optimization strategies 208 to MDSC. MDSC sends the corresponding path traffic monitoring 209 request to PNC. Traffic monitoring parameters and monitoring cycle 210 need to be carried in 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 MDSC. According to the traffic optimization strategy 216 obtained from the customer controller, MDSC determines whether the 217 service needs to be adjusted, or a new connection should be created. 218 If it needs to, then MDSC send the traffic monitoring results to the 219 customer controller, indicating that the service needs adjustment. 221 Customer Network Controller confirms whether the service can be 222 optimized then sends a service adjustment request to MDSC. MDSC will 223 convert it into path modification or creation request, and send it 224 to PNC to complete the service optimization. Then, PNC returns the 225 optimization results to MDSC, and MDSC passes the results to the 226 customer controller. 228 +-------------------------------------------+ 229 | CNC +-----------------------------+ | 230 | | Dynamic Service Control APP | | 231 | +-----------------------------+ | 232 +-------------------------------------------+ 233 1.Traffic| /|\4.Traffic | /|\ 234 Monitor& | | Monitor | | 8.Traffic 235 Optimize | | Result 5.Service | | modify & 236 Policy | | modify& | | optimize 237 \|/ | optimize Req.\|/ | result 238 +------------------------------------------------+ 239 | MDSC +-------------------------------+ | 240 | |Dynamic Service Control Agent | | 241 | +-------------------------------+ | 242 | +---------------+ +-------------------+ | 243 | | Flow Optimize | | vConnection Agent | | 244 | +---------------+ +-------------------+ | 245 +------------------------------------------------+ 246 2. Path | /|\3.Traffic | | 247 Monitor | | Monitor | |7.Path 248 Request | | Result 6.Path | | modify & 249 | | modify& | | optimize 250 \|/ | optimize Req.\|/ | result 251 +-------------------------------------------------------+ 252 | PNC +----------------------+ +----------------------+ | 253 | | Network Provisioning | |Abstract Topology Gen.| | 254 | +----------------------+ +----------------------+ | 255 | +------------------+ +--------------------+ | 256 | |Network Monitoring| |Physical Topology DB| | 257 | +------------------+ +--------------------+ | 258 +-------------------------------------------------------+ 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 MDSC. 271 MDSC 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, translates the 278 performance results of the physical topology to the performance 279 information of the abstract topology, and reports to MDSC. MDSC 280 determines whether the relevant performance parameters can satisfy 281 the SLA agreements. If the performance degradation seriously 282 influences the service, such as service packet delay exceeds the 283 performance threshold, MDSC will immediately start the optimization 284 and adjustment. Then the performance monitoring results as well as 285 the optimizing or adjusting results will be send to the Customer 286 Network Controller. 288 +-------------------------------------------+ 289 | CNC +-----------------------------+ | 290 | | Dynamic Service Control APP | | 291 | +-----------------------------+ | 292 +-------------------------------------------+ 293 1. SLA& | /|\6.SLA | 294 Optimize | | Monitor, modify & | 295 Policy | | Optimize | 296 | | Result | 7.Ack 297 \|/ | \|/ 298 +---------------------------------------------+ 299 | MDSC +-------------------------------+ | 300 | |Dynamic Service Control Agent | | 301 | +-------------------------------+ | 302 | +---------------+ +-------------------+ | 303 | | Flow Optimize | | vConnection Agent | | 304 | +---------------+ +-------------------+ | 305 +---------------------------------------------+ 306 2. Path | /|\3.SLA | /|\ 307 Monitor | | Monitor | |5.Path 308 Request | | Result 4.Path | | Modify & 309 | | Modify& | | Optimize 310 \|/ | Optimize Req.\|/ | Result 311 +---------------------------------------------------------+ 312 | PNC +----------------------+ +----------------------+ | 313 | | Network Provisioning | |Abstract Topology Gen.| | 314 | +----------------------+ +----------------------+ | 315 | +------------------+ +--------------------+ | 316 | |Network Monitoring| |Physical Topology DB| | 317 | +------------------+ +--------------------+ | 318 +---------------------------------------------------------+ 319 Figure 2 Workflows for dynamic service control based on SLA 320 monitoring 322 4. Requirement for ACTN Interface 324 ACTN Interfaces defined [ACTN-FWK] includes the following: 326 o CNC-MDSC Interface (CMI): an interface between a Customer Network 327 Controller and a Multi Service Domain Controller. 329 o MDSC-PNC Interface (MPI): an interface between a Multi Service 330 Domain Controller and a physical network controller. 332 4.1. Interface Requirements for Dynamic Service Control Based on 333 Traffic Monitoring 335 According to the work flow of dynamic service control based on 336 performance monitoring, the information carried in CMI interface 337 mainly relates to the traffic monitoring and control strategy, while 338 the MPI interface mainly relates to transports path related traffic 339 monitoring parameters and results. 341 1. CMI Interface 343 The following information is used by the customer network controller 344 to send to MDSC through the CMI interface. 346 o Customer service performance monitoring strategy, including the 347 traffic monitoring object (the service need to be monitored), 348 monitoring parameters (e.g., transmitted and received bytes per 349 unit time), traffic monitoring cycle (e.g., 15 minutes, 24 hours), 350 threshold of traffic monitoring (e.g., high and low threshold), 351 etc. 353 o Customer service optimization strategy, such as enabling service 354 creation or modification when traffic exceeds the threshold. 356 The following information is used for MDSC to send to the customer 357 network controller through MPI interface. 359 o Traffic monitoring results, to indicate if the traffic exceeds 360 the bandwidth threshold. 362 2. MPI Interface 364 The following parameters are used for MDSC to send to PNC. 366 o Traffic monitoring parameters, monitoring object, monitoring cycle, 367 performance threshold. 369 The following information is used for PNC to send to MDSC. 371 o Traffic monitoring results. These results must be translated from 372 the physical topology to abstract topology by the Abstract 373 Topology Generalization module firstly. 375 4.2. Interface Requirements of Dynamic Service Control based on SLA 376 monitoring 378 According to the work flow of dynamic service control based on SLA 379 monitoring, the information in VCI interface mainly contains the SLA 380 related information and measurement strategy, while the MPI 381 interface mainly transports path related performance monitoring 382 parameters and results. 384 1. CMI Interface 386 The following information is used by the customer network controller 387 to send to the MDSC through CMI interface. 389 o SLA related performance requirement information, including the 390 required quality of service parameters (e.g., BER, delay, delay 391 jitter, packet loss rate, throughput, etc.). 393 o Service optimization strategy, including the service performance 394 degradation thresholds and the consequent operations that are 395 allowed (e.g., rerouting). 397 The following information is used by the customer network controller 398 to send to MDSC. 400 o Monitoring results of service performance, including performance 401 monitoring parameters, and the services that have been influenced. 403 o Service optimization results based on performance. 405 2. MPI Interface 407 The following information is used by MDSC to send to PNC. 409 o The path performance monitoring request parameters, monitoring 410 cycle and threshold. 412 The following information is used for PNC sending to MDSC. 414 o Path performance monitoring results. 416 4.3. Discussion 418 Performance monitoring in a large scale network could generate a 419 huge amount of performance information. Therefore, the appropriate 420 way to deliver the information in CMI and MPI interfaces should be 421 carefully considered. 423 5. Security Considerations 425 This document raises no new security issues. 427 6. IANA Considerations 429 No new IANA considerations are raised by this document. 431 7. References 433 7.1. Informative References 435 [ACTN-FWK] Daniele C., Luyuan Fang, Yong Lee and Diego Lopez, 436 "Framework for Abstraction and Control of Transport 437 Networks",draft-ceccarelli-actn-framework-07. 439 Authors' Address 441 Yunbin Xu 442 China Academy of Telecom Research 443 NO.52 Huayuan Beilu, Haidian District, Beijing, China 444 Email: xuyunbin@catr.cn 446 Guoying Zhang 447 China Academy of Telecom Research 448 NO.52 Huayuan Beilu, Haidian District, Beijing, China 449 Email: zhangguoying@catr.cn 451 Weiqiang Cheng 452 China Mobile Communication Company 454 Email:chengweiqiang@chinamobile.com 456 Haomian Zheng 457 Huawei Technologies 458 F3-1-B R&D Center, Bantian, Longgang District Shenzhen, China 459 Email: zhenghaomian@huawei.com