idnits 2.17.1 draft-yangh-cso-oaas-11.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (November 13, 2016) is 2713 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 103 -- Looks like a reference, but probably isn't: '2' on line 104 -- Looks like a reference, but probably isn't: '3' on line 109 -- Looks like a reference, but probably isn't: '4' on line 536 == Unused Reference: 'Ref1' is defined on line 641, but no explicit reference was found in the text == Unused Reference: 'Ref2' is defined on line 645, but no explicit reference was found in the text == Unused Reference: 'Ref3' is defined on line 649, but no explicit reference was found in the text == Unused Reference: 'Ref4' is defined on line 653, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Cross Stratum Optimization Research Group H. Yang 3 Internet-Draft YL. Zhao 4 Intended status: Informational J. Zhang 5 Expires: May 17, 2017 Beijing University of Posts and Telecommunications 6 Y. Lee 7 Y. Lin 8 FT. Zhang 9 Huawei Technologies Co., Ltd. 10 November 13, 2016 12 Cross Stratum Optimization Architecture for Optical as a Service 13 draft-yangh-cso-oaas-11 15 Abstract 17 Data centers based applications provide a wide variety of services 18 such as cloud computing, video gaming, grid application and others. 19 Currently application decisions are made with little information 20 concerning underlying network used to deliver those services so that 21 such decisions cannot be the most optimal from both network and 22 application resource utilization and quality of service objectives. 24 This document presents a novel architecture of Cross Stratum 25 Optimization for application and network resource in dynamic optical 26 networks. Several global load balancing strategies are proposed and 27 demonstrated by experiments in Optical as a Service experimental 28 environment. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on May 17, 2017. 47 Copyright Notice 49 Copyright (c) 2016 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 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 66 2. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 3 67 3. CSO Functional Architecture for OaaS . . . . . . . . . . . . 5 68 3.1. AC . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 3.2. SC . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 4. Advantage of CSO Architecture for OaaS . . . . . . . . . . . 8 71 5. CSO Procedure in CSO Architecture for OaaS . . . . . . . . . 8 72 6. Different Application Scenarios . . . . . . . . . . . . . . . 9 73 6.1. Network Resource Acquirement . . . . . . . . . . . . . . 9 74 6.2. Virtual Migration Request . . . . . . . . . . . . . . . . 9 75 6.3. Exception Handling . . . . . . . . . . . . . . . . . . . 10 76 7. Definition of New Interfaces in CSO Architecture for OaaS . . 10 77 7.1. Functional Requirement for UAI . . . . . . . . . . . . . 10 78 7.2. Functional Requirement for ASI . . . . . . . . . . . . . 10 79 7.3. Functional Requirement for SCI . . . . . . . . . . . . . 11 80 7.4. Functional Requirement for SMI . . . . . . . . . . . . . 11 81 8. CSO Strategies and Algorithms . . . . . . . . . . . . . . . . 11 82 9. CSO Experiment and Demonstration . . . . . . . . . . . . . . 13 83 9.1. CSO Experimental Environment . . . . . . . . . . . . . . 13 84 9.2. CSO Experimental Results . . . . . . . . . . . . . . . . 13 85 10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 86 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 87 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 88 12.1. Normative References . . . . . . . . . . . . . . . . . . 15 89 12.2. Informative References . . . . . . . . . . . . . . . . . 15 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 92 1. Introduction 94 With the emergence of cloud computing and high-bandwidth video 95 applications such as live concerts, sporting events and remote 96 medical surgery, various data center applications become more and 97 more important, some Quality of Service related parameters of which 98 have attracted much attention, such as jitter and latency. 99 Therefore, there is a great need for a joint scheduling of network 100 and application resources, the latter of which mainly refers to 101 computing and storage resource, such as servers of various types and 102 granularities (memory, disk, VMs). Many studies have been focused on 103 traffic awareness in application resource [1], especially cross layer 104 optimization in optical network [2]. However, few of them have been 105 involved in global combined optimization of network and application 106 resources. 108 This document proposes a novel architecture based on Cross Stratum 109 Optimization (CSO) [3] that enables a joint application/network 110 resource optimization, responsiveness to quickly change demands from/ 111 to application to/from network, enhanced service resilience (via 112 cooperative recovery techniques between application and network) and 113 quality of application experience (QoE) enhancement (via better use 114 of current network and application resources). This architecture is 115 intended to enable Optical as a Service (OaaS) by enabling large- 116 bandwidth and multi-granularities applications based on Adaptive 117 Multi-service Optical Networks (AMSON) with an increased resource 118 utilization and resiliency across the application and network 119 stratums. Four strategies including global load balancing (GLB), 120 random based (RB), application resource based (AB) and network 121 resource based (NB) strategies are proposed and validated in our 122 experimental environment. Experimental results show that GLB in CSO 123 architecture performs more effective compared with others. 125 1.1. Conventions Used in This Document 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 129 document are to be interpreted as described in [RFC2119]. 131 2. Terminologies 133 AB: Application resource Based. 135 AC: Application Controller. 137 AMSON: Adaptive Multi-service Optical Networks. 139 ARAE: Application Resource Abstract Engine. 141 ASI: Application-Service Interface. 143 CSO: Cross Stratum Optimization. 145 DB: Data Base. 147 DBM: Data Base Management. 149 DCN: Data Center Network. 151 GLB: Global Load Balancing. 153 GMPLS: General Multi-Protocol Label Switching. 155 LSA: Link State Advertisement. 157 MIB: Management Information Base. 159 NB: Network resource Based. 161 NRAA: Network Resource Abstraction Algorithm. 163 NRAE: Network Resource Abstract Engine. 165 NRDB: Network Resource Database. 167 NMS: Network Management System. 169 OaaS: Optical as a Service. 171 OAM: Operation Administration and Maintenance. 173 OSPF: Open Shortest Path First. 175 PA: Protocol Agent. 177 PCE: Path Computation Element. 179 QoE: Quality of Experience. 181 RB: Random Based. 183 SA: Service Agent. 185 SA-PCE: Service-Aware PCE enhancement algorithm. 187 SC: Service Controller. 189 SCI: Service-Control plane Interface. 191 SMI: Service-Management Plane Interface. 193 SSE: Server/VM Selection Engine. 195 TED: Traffic Engineering Database. 197 UA: User Agent. 199 UAI: User-Application Interface. 201 VM: Virtual Machine. 203 3. CSO Functional Architecture for OaaS 205 The CSO functional architecture for OaaS is illustrated in Fig. 1 and 206 Fig. 2. 208 ------------------------------------- ---------- 209 | ------- | | | 210 | | SSE |\ | | | 211 | / ------- \ ------ | | | 212 | / | | DB | | ------------ | | 213 | / | ------ |--| User Plane |--| | 214 | / | / | ------------ | | 215 | ------ / -------- / | | | 216 | | UA |-----| ARAE | AC |------------------| | 217 | ------ -------- | | | 218 -----|------------------------------- | | 219 | | | 220 | | | 221 -----|------------------ ------------------------- |Management| 222 | ------ ------ | | ----------- | | Plane | 223 || | | |--|--|--| Signaling | |--| | 224 || SA |------| PA | | | ----------- | | | 225 || |\ | |--|--|-- --------- | | | 226 | ------ \ ------ | | | OSPF-TE | | | | 227 | | \ | | | ---------Control Plane| | | 228 | | \ | | ------------------------- | | 229 | | \ | | | | | 230 | -------- \ ------- | ------------------ | | | 231 || NRAE |----| PCE |-|--| Other domain SCs | | | | 232 | -------- ------- | ------------------ | | | 233 | \ | | ----------------------- | | 234 | \ | | | Transport Plane |----| | 235 | \ ------- | ----------------------- | | 236 | SC \| DBM |-|-------------------------------| | 237 | ------- | | | 238 ------------------------ ---------- 240 Fig.1 CSO functional architecture for OaaS 242 ------------------------------------------------------- 243 | -------- ------------ --------- | 244 | | DCNs |------| AC |-------| Users | | 245 | -------- / ------------ \ --------- | 246 | / | \ Application Stratum | 247 |---------------/--------|---------\--------------------| 248 | / | \ Network Stratum | 249 | ------ ------ ------ | 250 | | SC | | SC | | SC | | 251 | ------ ------ ------ | 252 | | | | | 253 | | | | | 254 | ------------ ------------ ------------ | 255 | | | | | | | | 256 | | domain A |--| domain B |--| domain C | | 257 | | | | | | | | 258 | ------------ ------------ ------------ | 259 ------------------------------------------------------- 261 Fig.2 CSO schematic for OaaS 263 The application stratum plane, service stratum plane and user plane 264 are introduced in the novel architecture of CSO besides traditional 265 planes, i.e., control plane, management plane and transport plane. 266 The responsibility for centralized application stratum plane is 267 concerned with maintaining application resources in data centers, 268 while service stratum plane provides to application stratum the 269 network resource information abstracted from control plane with NRAA. 270 In addition, GLB computation is implemented based on both the 271 application stratum and network stratum resources, while service 272 stratum will enforce SA-PCE. The responsibilities and interactions 273 among these entities are provided below. 275 3.1. AC 277 AC comprises UA, SSE, DB and ARAE. AC is responsible for interacting 278 with user plane and obtaining network and application resource 279 abstract information abstracted from SCs and DCNs. AC completes the 280 GLB computation based on them. UA authenticates the user requests 281 and maintains user information. With GLB computation, SSE chooses 282 the optimal server or VM for users, allocates application resources, 283 and determines the location of the distributed application or where 284 to migrate virtual machines. ARAE provides to GLB computation the 285 suited application resource abstract information obtained from DCNs, 286 such as running state and idle resource of servers or VMs. 288 3.2. SC 290 SC is composed of SA, PA, PCE, NRAE and DBM. Three main functional 291 requirements for SC in OaaS architecture are described below. 292 Firstly, SC provides network services to AC. According to the type 293 of services, SC computes the paths and drives control plane to 294 establish the paths so as to implement the concept of OaaS. 295 Secondly, SC offers to AC the resources abstract information 296 including the mapping of application and optical layer, logical 297 topology of optical layer and the status of network transmission for 298 AC decision. Finally, it provides to management plane the database 299 interface so that network administrator can monitor it. 301 SA communicates to AC with authentication and access control 302 permission of transport network resources through ASI. SA also 303 translates AC profile into connection and service parameters in 304 transport network which contains bandwidth, delay, jitter and others. 305 PA drives the GMPLS signaling of control plane and receives the 306 routing information. PCE enforce SA-PCE while NRAE abstracted from 307 control plane with NRAA. In addition, TED, NRDB, MIB and 308 configuration are contained in DBM. 310 4. Advantage of CSO Architecture for OaaS 312 CSO Architecture for OaaS is the spread of traditional three planes, 313 i.e., control plane, management plane and transport plane. The 314 decisions based on CSO architecture for OaaS can be the most optimal 315 and have the least cost from both application and network resource 316 utilization, while the quality of user experience can reach the 317 highest in this architecture. According to various demands and 318 expenses of different server providers, the operator can provide to 319 them abstract topologies with NRAA so that this mechanism guarantees 320 the security between operator and server provider or among server 321 providers. Since the CSO architecture for OaaS is based on new 322 strategies and algorithms, the spread of current network may be just 323 software promotional and the architecture is provided with the higher 324 expansibility and flexibility. 326 5. CSO Procedure in CSO Architecture for OaaS 328 When the UA in AC receives the application request from user plane, 329 it will forward this request to SSE after authenticating the user 330 requests. The certified request is analyzed via SSE and transmitted 331 to ARAE for the application resource information. SSE receives the 332 network abstract information from SC via AC gateway upon request. 333 ARAE responds to SSE the suited application resource abstract 334 information obtained from DCNs, according to the analysis result from 335 it. Upon completing the GLB computation based on application and 336 network abstract resource, and SSE chooses the most optimal server or 337 VM for users, allocates application resources, and determines the 338 location of the distributed application or where to migrate virtual 339 machines. According to service type, resources occupancy rate and 340 QoE, UA performs accounting function and transmits the application 341 requirements to SC via ASI. UA receives the responses to NRAE and 342 returns to UA. Rating the service based on the distribution of 343 resources and returning the feedback, UA provides to user stratum the 344 resources at last. When SA receives the location of the server/VM 345 and the service type, it will translate this profile into connection 346 and service parameters in transport network which contains bandwidth, 347 delay, jitter and others after authentication and access control 348 permission to this requirement. SA also forwards the network 349 resource profile to PCE at the same time. Completing SA-PCE 350 computation that factors in the connection and service parameters 351 constraints, SA-PCE provides the explicit route to PA. Then using 352 the RSVP signaling protocol, PA drives control plane to establish the 353 path through SCI. After the path is setup successfully, it will 354 conserve the information of the path into DBM and return overall 355 results including transport network resource to AC. After receiving 356 the OSPF LSA from control plane, PA provides it to DBM for network 357 resources synchronization. AC obtains application and network 358 information periodically or based on event-based trigger. Meanwhile, 359 NRAE interacts with network TE topology information base and DBM for 360 abstracting network resource. NRAE provides abstract information to 361 the authorized AC using NRAA. 363 6. Different Application Scenarios 365 6.1. Network Resource Acquirement 367 SCs receive the OSPF LSA from control plane to obtain the completely 368 TE topology information network and provide it to DBM for network 369 resources synchronization. AC obtains application and network 370 information periodically or based on event-based trigger. Based on 371 NRAA, SCs computes the abstract topology and feedback to AC. 373 6.2. Virtual Migration Request 375 Due to the insufficiency of network or servers/VMs resource, or the 376 abrupt emergency to servers or network, or the requirement of saving 377 energy consumption, Virtual migration request becomes significant in 378 reality application. Virtual migration migrates to the destination 379 server with multi-granularities and the choice of destination one 380 follows the procedure of CSO in OaaS architecture. 382 6.3. Exception Handling 384 When unexpected error happens in the process of CSO, SC will receive 385 GMPLS OAM from control plane and provide the alarm information to AC 386 and saves into DBM. SC needs to route again as the service delivery 387 process. 389 7. Definition of New Interfaces in CSO Architecture for OaaS 391 Due to additional planes in OaaS architecture, new interfaces between 392 themselves, which contain ASI, UAI, and which between them and 393 traditional planes in GMPLS containing SCI, SMI is to be defined in 394 this section. Nevertheless, only functional requirement will be 395 demonstrated for each of above-mentioned interfaces, by which service 396 of OaaS and Cross Stratum Optimization could work well. 398 7.1. Functional Requirement for UAI 400 UAI is the interface between user plane and application plane, which 401 conveys the user's application request from user plane to application 402 plane and the reply information. Such user denotes the general users 403 who apply for the application, not only includes the particular 404 clients asking for video service, but also revolves the service 405 provider managing the application resource such as virtual migration. 406 In other words, managers of the service provider access the 407 application Plane by the same interface, even if the permission will 408 differ common users. 410 Whatever kinds of application request is submitted, UAI should 411 transmit the request information transparently, which consists of the 412 user identity, request type, specified information. 414 7.2. Functional Requirement for ASI 416 ASI is the interface between service plane and application plane, 417 which conveys the request for optical service of all application, 418 containing path establishment request and network resource abstract 419 request. The latter is foundation to CSO, because the replied 420 abstract information will be referred to for application plane to 421 make a judgment, such as selecting a proper datacenter for a user or 422 to which migrating virtual machines. Therefore, the interface from 423 SC to AC should convey the whole abstraction information, which is 424 abstracted and packed by abstracting module in SC, as well as optical 425 service reply. 427 As to the common request for optical service, the request information 428 must include the service style, such as VOD and virtual migration, 429 and the source and destination node in optical layer of this service. 431 The reply of which also contains the path establishment result and if 432 it is failure, the reason should be given. 434 7.3. Functional Requirement for SCI 436 SCI is the interface between service plane and control plane. The 437 message transmitted through this interface is standard GMPLS 438 including OSPF and RSVP messages, which is easily compatible to GMPLS 439 control plane. 441 7.4. Functional Requirement for SMI 443 SMI is the interface between service plane and management plane. The 444 database of the network information maintained by SC, could supply 445 some detailed network operating condition for management plane to 446 make decision, and management plane also can issue OAM commands to 447 SC. Both state information and OAM message will be defined by SMI. 449 8. CSO Strategies and Algorithms 451 Based on functional architecture of CSO-OaaS described above, we 452 propose four strategies including GLB strategy based on CSO, RB, AB 453 and NB strategies. These strategies and related algorithms are 454 described in detail below. 456 With RB strategy, the destination node of data center server is 457 randomly selected by control plane when the application request 458 comes. With AB strategy, according to the CPU, memory, disk 459 utilization and I/O scheduling, control plane chooses the server node 460 having the minimum application utilization as the destination. NB 461 strategy selects the node which has the path of the minimum network 462 hop from the source to the destination. With GLB strategy, as 463 described in previous sections, AC selects the server node and the DC 464 location based on the application status collected from data center 465 networks and the network condition provided by SCs dynamically. 467 We define alpha as the joint optimization factor to measure the 468 balance between the network and application resources, which contains 469 the application and network parameters. Three application 470 parameters, current memory utilization Ur which models RAM, CPU usage 471 Uc and the utilization of I/O scheduling Us describe the current 472 usage of data center application resource. The network parameters 473 are comprised of the TE weight Bl and delay tl which is related to 474 traffic cost and delay of the current link and the hop Hp of the 475 candidate path. These parameters are normalized to meet the linear 476 relationship between them. The application function with application 477 parameters of current each node is expressed as dimensionless overall 478 function fac(Ur,Uc,Us,k) = kc*Uc+kr*Ur+ks*Us, kc+kr+ks=1, kc>=0, 479 kr>=0, ks>=0, where kc,kr,ks are adjustable evaluation rank rate 480 among CPU, RAM utilization and I/O scheduling. Initially, the 481 evaluation rank of CPU is the highest of all, while the rank of RAM 482 is higher than I/O scheduling. At this point, evaluation ranks 483 satisfy the expressions as follows: kc=Ra, kr=Rb, ks=Rc, Ra+Rb+Rc=1, 484 Ra>=Rb>=Rc, where Ra,Rb,Rc are constants and their priorities 485 decrease increasingly. That means the higher utilization corresponds 486 to higher priority. Once Ur or Us exceeds Uc, for instance 487 Ur>=Uc>=Us, the evaluation rank of them will adjust according to this 488 change as follows: kc=Rb, kr=Ra, ks=Rc. By parity of reasoning, 489 kc,kr,ks will modify dynamically based on the feedback of utilization 490 variation. In addition, network function with parameters of current 491 each node is expressed as dimensionless overall function 492 fbc(Bl,Hp,tl) = 493 kB*(B1+B2+...+Bl+...+BHp)/B*Hp+kt*(t1+t2+...+tl+...+tHp)/t*Hp, which 494 the candidate path is calculated by the network stratum resources 495 with candidate server destination nodes chosen by AC. fa1, 496 fa2,...,fak are the application functions with parameters among the K 497 candidate server nodes and fb1, fb2,...,fbk are the network functions 498 with parameters associated with the K candidate paths. So the joint 499 optimization factor alpha meets the formula as follows. In this 500 formula, beta is the dynamic weight between the network and 501 application parameter, which associates with the variance of 502 application parameters from each server node. The variance is 503 related to DC load balancing degree, while the larger variance 504 represents balancing degree becomes worse in DCs. Based on the 505 formula described below, the application utilization weight changes 506 dynamically according to the feedback of load balancing degree. At 507 first, the weight of application utilization is relatively smaller 508 due to the lower application parameters variance. With the 509 increasing of application parameters variance, the application 510 utilization weight turns into higher, which miu is normalizing factor 511 of beta. The formula is alpha = 512 [fac(Ur,Uc,Us,k)/max(fa1,fa2,...,fak)]*beta + 513 [fbc(Bl,Hp,tl)/max(fb1,fb2,...,fbk)]*(1-beta), beta = 514 miu*sqrt{var(fa)/max[ var(fa1),var(fa2),...,var(fak)]}. 516 According to application utilization, AC first chooses the K 517 candidate server nodes in application stratum, which can provide this 518 type of application. In network stratum, the node with minimum alpha 519 value based on the joint optimization factor will be selected from 520 the K candidates. In all schemes, the path will be reserved and 521 setup through signalling protocol between the source and destination 522 node after the choice of the node. 524 9. CSO Experiment and Demonstration 526 9.1. CSO Experimental Environment 528 Experimental environment is built to support the architecture of CSO 529 and deployed in five servers, while each server mounts virtual 530 machines created by VMware software running at servers. Since each 531 virtual machine has the operation system and its own computation 532 resource, the virtual OS technology makes it easy to set up 533 experiment topology based upon NSFNET with 14 control plane nodes. 534 In addition, Network Management System (NMS) is placed to monitor and 535 initialize the transport plane elements, while NMS is an inseparable 536 management system which manages the overall network.[4] The service 537 application usage is selected randomly from 1% to 0.1% for each 538 application demand and network bandwidth required for each 539 application is assumed one wavelength equivalent. Each node supports 540 40 wavelengths with no wavelength conversion or 3R regeneration 541 capability. 543 9.2. CSO Experimental Results 545 Based on CSO functional architecture described above, GLB strategy 546 based on the cross-stratum optimization is implemented and 547 experimentally compared with RB, AB and NB strategies in CSO 548 Experimental environment. The experimental results are shown in Tab. 549 1-4. Tab. 1 illustrates load balancing degree resulting from RB, AB, 550 NB and GLB strategy. The load balancing degree is defined as the 551 variance of application utilization in each data center server. The 552 higher load balancing degree is, the worse the effect of load 553 balancing is. As shown, GLB strategy leads to much lower load 554 balancing degree than RB and NB strategy, but higher than AB 555 strategy. In fact, AB strategy computes the node only considered 556 application utilization, the path may not be able to setup because it 557 does not have enough wavelength resource. In Tab. 2, GLB has less 558 network blocking probability than RB and AB strategies. Tab. 3 shows 559 that GLB approach has less average hop than RB and AB strategies 560 obviously, for it factors the latency. With the increase of offered 561 load, the curve of GLB scheme gets closer to NB. In Tab. 4, global 562 blocking probability measures both the network and application 563 blocking situation measured by CPU and memory overflow. Though AB 564 approach has lower load balancing degree and similar average hop is 565 computed through NB scheme, GLB strategy has significantly lower 566 integrated blocking probability than all other approaches. 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 | | Load balancing degree | 570 | Traffic load +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 | | RB | AB | NB | GLB | 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 | 100 |0.00594 |7.65E-5 |0.05639 |0.00333 | 574 | 200 |0.00951 |7.77E-5 |0.10181 |0.00361 | 575 | 300 |0.01286 |7.85E-5 |0.12019 |0.0036 | 576 | 400 |0.01409 |7.49E-5 |0.12352 |0.00334 | 577 | 500 |0.01198 |7.8E-5 |0.12043 |0.00303 | 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 Tab.1 Load balance factor of four strategies 582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 | | Network blocking probability | 584 | Traffic load +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 585 | | RB | AB | NB | GLB | 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 587 | 100 |0.00002 |6.5E-4 |7.6E-4 |5E-5 | 588 | 200 |0.01902 |0.01866 |0.02152 |5.2E-4 | 589 | 300 |0.08462 |0.09368 |0.05992 |0.03628 | 590 | 400 |0.15036 |0.17944 |0.08968 |0.12418 | 591 | 500 |0.19862 |0.25528 |0.10462 |0.18104 | 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 Tab.2 Network blocking probability of four strategies 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 | | Average hop | 598 | Traffic load +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 | | RB | AB | NB | GLB | 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 | 100 |5.50661 |5.5058 |3.604 |4.2668 | 602 | 200 |5.48937 |5.4813 |3.59706 |4.25557 | 603 | 300 |5.42255 |5.40668 |3.56946 |4.23117 | 604 | 400 |5.34908 |5.31895 |3.5374 |4.1668 | 605 | 500 |5.28607 |5.21635 |3.50851 |4.0981 | 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 Tab.3 Average hop of four strategies 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 | | Global blocking probability | 612 | Traffic load +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 | | RB | AB | NB | GLB | 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 | 100 |2E-5 |6.5E-4 |0.00162 |5E-5 | 616 | 200 |0.02902 |0.01866 |0.06412 |5.2E-4 | 617 | 300 |0.0975 |0.09368 |0.1776 |0.03628 | 618 | 400 |0.18458 |0.17944 |0.2843 |0.12864 | 619 | 500 |0.27046 |0.25528 |0.36988 |0.19704 | 620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 Tab.4 Global blocking probability of four strategies 624 10. Security Considerations 626 TBD 628 11. Acknowledgments 630 The RFC text was produced using Marshall Rose's xml2rfc tool. 632 12. References 634 12.1. Normative References 636 [RFC2119] Bradner, S., "Key words for use in RFC's to Indicate 637 Requirement Levels", RFC 2119, March 1997. 639 12.2. Informative References 641 [Ref1] Meng, Xiaoqiao., Pappas, V., and Li. Zhang, "Improving the 642 Scalability of Data Center Networks with Traffic-aware 643 Virtual Machine Placement", May 2010. 645 [Ref2] Christodoulopoulos, K., Manousakis, K., and E. Varvarigos, 646 "Cross Layer Optimization of Static Lightpath Demands in 647 Transparent WDM Optical Networks", July 2009. 649 [Ref3] Lee, Young., Bernstein, Greg., So, Ning., Kim, Tae., 650 Shiomoto, Kohei., and Oscar. Dios, "draft-lee-cross- 651 stratum-optimization-datacenter-00", March 2011. 653 [Ref4] Zhang, Jie., Chen, Xue., and Yuefeng. Ji, "Experimental 654 Demonstration of a DREAM-based Optical Transport Network 655 with 1000 Control Plane Nodes, ECOC2011", September 2011. 657 Authors' Addresses 659 Hui Yang 660 Beijing University of Posts and Telecommunications 661 No.10,Xitucheng Road,Haidian District 662 Beijing 100876 663 P.R.China 665 Phone: +8613466774108 666 Email: yang.hui.y@126.com 667 URI: http://www.bupt.edu.cn/ 669 Yongli Zhao 670 Beijing University of Posts and Telecommunications 671 No.10,Xitucheng Road,Haidian District 672 Beijing 100876 673 P.R.China 675 Phone: +8613811761857 676 Email: yonglizhao@bupt.edu.cn 677 URI: http://www.bupt.edu.cn/ 679 Jie Zhang 680 Beijing University of Posts and Telecommunications 681 No.10,Xitucheng Road,Haidian District 682 Beijing 100876 683 P.R.China 685 Phone: +8613911060930 686 Email: lgr24@bupt.edu.cn 687 URI: http://www.bupt.edu.cn/ 689 Young Lee 690 Huawei Technologies Co., Ltd. 691 Huawei Base,Bantian,Longgang District,Shenzhen 692 Shenzhen 518129 693 P.R.China 695 Email: leeyoung@huawei.com 696 URI: http://www.huawei.com/ 697 Yi Lin 698 Huawei Technologies Co., Ltd. 699 Huawei Base,Bantian,Longgang District,Shenzhen 700 Shenzhen 518129 701 P.R.China 703 Email: yi.lin@huawei.com 704 URI: http://www.huawei.com/ 706 Fatai Zhang 707 Huawei Technologies Co., Ltd. 708 Huawei Base,Bantian,Longgang District,Shenzhen 709 Shenzhen 518129 710 P.R.China 712 Email: zhangfatai@huawei.com 713 URI: http://www.huawei.com/