idnits 2.17.1 draft-dhody-pce-cso-enabled-path-computation-05.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 abstract seems to contain references ([CSO-DATACNTR], [RFC4655]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 19, 2014) is 3749 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-13) exists of draft-ietf-pce-pcep-service-aware-01 == Outdated reference: A later version (-21) exists of draft-ietf-pce-stateful-pce-06 == Outdated reference: A later version (-04) exists of draft-lee-alto-app-net-info-exchange-02 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group D. Dhody 3 Internet-Draft Y. Lee 4 Intended status: Informational Huawei Technologies 5 Expires: July 23, 2014 LM. Contreras 6 O. Gonzalez de Dios 7 Telefonica I+D 8 N. Ciulli 9 Nextworks 10 January 19, 2014 12 Cross Stratum Optimization enabled Path Computation 13 draft-dhody-pce-cso-enabled-path-computation-05 15 Abstract 17 Applications like cloud computing, video gaming, HD Video streaming, 18 Live Concerts, Remote Medical Surgery, etc are offered by Data 19 Centers. These data centers are geographically distributed and 20 connected via a network. Many decisions are made in the Application 21 space without any concern of the underlying network. Cross stratum 22 application/network optimization focus on the challenges and 23 opportunities presented by data center based applications and 24 carriers networks together [CSO-DATACNTR]. 26 Constraint-based path computation is a fundamental building block for 27 traffic engineering systems such as Multiprotocol Label Switching 28 (MPLS) and Generalized Multiprotocol Label Switching (GMPLS) 29 networks. [RFC4655] explains the architecture for a Path Computation 30 Element (PCE)-based model to address this problem space. 32 This document explains the architecture for CSO enabled Path 33 Computation. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on July 23, 2014. 51 Copyright Notice 53 Copyright (c) 2014 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 69 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 70 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 3. CSO enabled PCE Architecture . . . . . . . . . . . . . . . . 6 72 4. Path Computation and Setup Procedure . . . . . . . . . . . . 10 73 4.1. Path Setup Using NMS . . . . . . . . . . . . . . . . . . 11 74 4.2. Path Setup Using a Network Control Plane . . . . . . . . 12 75 4.3. Path Setup using PCE . . . . . . . . . . . . . . . . . . 13 76 4.4. Path Setup Using a Software Defined Network controller . 14 77 5. Other Consideration . . . . . . . . . . . . . . . . . . . . . 15 78 5.1. Inter-domain . . . . . . . . . . . . . . . . . . . . . . 15 79 5.1.1. One Application Domain with Multiple Network Domains 15 80 5.1.2. Multiple Application Domains with Multiple Network 81 Domains . . . . . . . . . . . . . . . . . . . . . . . 16 82 5.1.2.1. ACG talks to multiple NCGs . . . . . . . . . . . 16 83 5.1.2.2. ACG talks to the primary NCG, which talks to the 84 other NCG of different domains . . . . . . . . . 17 85 5.1.3. Federation of SDN domains . . . . . . . . . . . . . . 18 86 5.2. Bottleneck . . . . . . . . . . . . . . . . . . . . . . . 19 87 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 88 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 89 8. Manageability Considerations . . . . . . . . . . . . . . . . 20 90 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 91 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 92 10.1. Normative References . . . . . . . . . . . . . . . . . . 20 93 10.2. Informative References . . . . . . . . . . . . . . . . . 20 95 1. Introduction 97 Many application services offered by Data Center to end-users make 98 significant use of the underlying networks resources in the form of 99 bandwidth consumption used to carry the actual traffic between data 100 centers and/or among data center and end-users. There is a need for 101 cross optimization for both network and application resources. 102 [CSO-PROBLEM] describes the problem space for cross stratum 103 optimization. 105 [NS-QUERY] describes the general problem of network stratum (NS) 106 query in Data Center environments. Network Stratum (NS) query is an 107 ability to query the network from application controller in Data 108 Centers so that decision would be jointly performed based on both the 109 application needs and the network status. Figure 1 shows typical 110 data center architecture. 112 --------------- 113 ---------- | DC 1 | 114 | End-user |. . . . .>| o o o | 115 | | | \|/ | 116 ---------- | O | 117 | ----- --|------ 118 | | 119 | | 120 | -----------------|----------- 121 | / | \ 122 | / ..........O PE1 \ -------------- 123 | | . | | o o o DC 2 | 124 | | PE4 . PE2 | | \|/ | 125 ----|---O.........................O---|---|---O | 126 | . | | | 127 | . PE3 | -------------- 128 \ ..........O Carrier / 129 \ | Network / 130 ---------------|------------- 131 | 132 --------|------ 133 | O | 134 | /|\ | 135 | o o o | 136 | DC 3 | 137 --------------- 139 Figure 1: Data Center Architecture 141 Figure 2 shows the context of NS Query within the overarching data 142 center architecture shown in Figure 1. 144 -------------------------------------------- 145 | Application Overlay | 146 | (Data Centers) | 147 | | 148 ---------- | -------------- -------------- | 149 | End-User | | | Application |. . . .| Application | | 150 | |. . . >| | Control | | Processes | | 151 ---------- | | Gateway (ACG)| -------------- | 152 | | | -------------- | 153 | ------------- . . . . | Application | | 154 | /\ | Related Data | | 155 | || -------------- | 156 ----------||-------------------------------- 157 || 158 || Network Stratum Query (First 159 || Stage) 160 || 161 ----------||-------------------------------- 162 | \/ Network Underlay | 163 | | 164 | -------------- ---------------- | 165 | | Network |. . . | Network | | 166 | | Control | | Processes | | 167 | | Gateway (NCG)| ---------------- 168 | | | ---------------- | 169 | ------------- | Network | | 170 | |------------->| Related Data | | 171 | (Second Stage) ---------------- | 172 ------------------------------------------- 174 Figure 2: NS Query Architecture 176 NS Query is a two-stage query that consists of two stages: 178 o A vertical query capability where an external point (i.e., the 179 Application Control Gateway (ACG) in Data Center) will query the 180 network (i.e., the Network Control Gateway (NCG)). The query can 181 be initiated either by ACG to NCG or NCG to ACG depending on the 182 mode of operation. ACG initiated query is an application-centric 183 mode while NCG initiated query is a network-centric mode. It is 184 anticipated that either ACG or NCG can be a final decision making 185 point that chooses the end-to-end resources (i.e., both 186 application IT resources and the network connectivity) depending 187 on the mode of operation. 189 o A horizontal query capability where the NCG gathers the collective 190 information of a variety of horizontal schemes implemented in the 191 network stratum. 193 As an example for vertical query (1st stage), [ALTO-APPNET] describes 194 Application Layer Traffic Optimization (ALTO) information model and 195 protocol extensions to support application and network resource 196 information exchange for high bandwidth applications in partially 197 controlled and controlled environments as part of the infrastructure 198 to application information exposure (i2aex) initiative. 200 For the horizontal query (2nd stage), PCE can be an ideal choice, 201 [CSO-PCE-REQT] describes the general requirement PCE should support 202 in order to accommodate CSO capability. This document is intended to 203 fulfill the general PCE requirements discussed in the aforementioned 204 reference. 206 This document describes how PCE Architecture as described in 207 [RFC4655] can help in the second stage of NS query. 209 1.1. Requirements Language 211 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 212 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 213 document are to be interpreted as described in [RFC2119]. 215 2. Terminology 217 The following terminology is used in this document. 219 ACG: Application Control Gateway. 221 Application Stratum: The application stratum is the functional block 222 which manages and controls application resources and provides 223 application resources to a variety of clients/end-users. 224 Application resources are non-network resources critical to 225 achieving the application service functionality. Examples 226 include: application specific servers, storage, content, large 227 data sets, and computing power. Data Centers are regarded as 228 tangible realization of the application stratum architecture. 230 ALTO: Application Layer Traffic Optimization. 232 CSO: Cross Stratum Optimization. 234 GMPLS: Generalized Multiprotocol Label Switching. 236 i2aex: Infrastructure to application information exposure. 238 LSR: Label Switch Router. 240 MPLS: Multiprotocol Label Switching. 242 NCG: Network Control Gateway. 244 Network Stratum: The network stratum is the functional block which 245 manages and controls network resources and provides transport of 246 data between clients/end-users to and among application resources. 247 Network Resources are resources of any layer 3 or below (L1/L2/L3) 248 such as bandwidth, links, paths, path processing (creation, 249 deletion, and management), network databases, path computation, 250 admission control, and resource reservation capability. 252 NMS: Network Management System 254 PCC: Path Computation Client: any client application requesting a 255 path computation to be performed by a Path Computation Element. 257 PCE: Path Computation Element. An entity (component, application, 258 or network node) that is capable of computing a network path or 259 route based on a network graph and applying computational 260 constraints. 262 PCEP: Path Computation Element Communication Protocol. 264 TE: Traffic Engineering. 266 TED: Traffic Engineering Database. 268 UNI: User Network Interface. 270 3. CSO enabled PCE Architecture 272 In the network stratum, the Network Control Gateway (NCG) serves as 273 the proxy gateway to the network. The NCG receives the query request 274 from the ACG, probes the network to test the capabilities for data 275 flows to/from particular points in the network, and gathers the 276 collective information of a variety of horizontal schemes implemented 277 in the network stratum. This is a horizontal query (Stage 2 in 278 Figure 2). 280 In this section we will describe how PCE fits in this horizontal 281 scheme. 283 A Path Computation Element (PCE) is an entity that is capable of 284 computing a network path or route based on a network graph, and of 285 applying computational constraints during the computation. 287 (1) NCG and PCE are co-located. 289 In this composite solution, the same node implements functionality of 290 both NCG and PCE. When a network stratum query is received from the 291 ACG (stage 1), this query is broken into one or more Path computation 292 requests and handled by the PCE functionality co-located with the 293 NCG. There is no need for PCEP protocol here. In this case, an 294 external PCE interface (e.g., CLI, SNMP, proprietary) needs to be 295 supported. This is out of the scope of this document. 297 +--------------------------------------------------+ 298 | -- -- -- -- -- -- -- -- -- | 299 | | | | | | | | | | | | | | | | | | | | 300 | -- -- -- -- -- -- -- -- -- | 301 | | 302 | Application Stratum | 303 | | 304 | +---------------------------------------+ | 305 | | | | 306 +----+ ACG +-----+ 307 | | 308 +------*---*----------------------------+ 309 | | 310 | | 311 | | 312 +------*---*----------------------------+ 313 | +----------+ +----------+ | 314 +----+ + *----------* * +-----+ 315 | | | NCG | | PCE | | | 316 | | | *----------* * | | 317 | | +----------+ +----------+ | | 318 | | | | 319 | +---------------------------------------+ | 320 | | 321 | Network Stratum | 322 | -- -- -- -- -- -- -- -- -- | 323 | | | | | | | | | | | | | | | | | | | | 324 | -- -- -- -- -- -- -- -- -- | 325 +--------------------------------------------------+ 327 Figure 3: NCG and PCE Collocated 329 (2) NCG and external PCE 331 In this solution, an external node implements PCE functionality. 332 Network stratum query received from the ACG (stage 1) is converted 333 into Path computation requests at the NCG and relayed to the external 334 PCE using the PCEP [RFC5440]. In this case the NCG includes Path 335 Computation Client (PCC) functionalities. 337 +--------------------------------------------------+ 338 | -- -- -- -- -- -- -- -- -- | 339 | | | | | | | | | | | | | | | | | | | | 340 | -- -- -- -- -- -- -- -- -- | 341 | | 342 | Application Stratum | 343 | | 344 | +---------------------------------------+ | 345 | | | | 346 +----+ ACG +-----+ 347 | | 348 +------*---*----------------------------+ 349 | | 350 | | 351 | | 352 +------*---*-------+ 353 | +----------+ | +----------+ 354 +----+ | | *------* *--------+ 355 | | | NCG | | | PCE | | 356 | | | | *------* * | 357 | | +----------+ | +----------+ | 358 | | | | 359 | +------------------+ | 360 | | 361 | Network Stratum | 362 | -- -- -- -- -- -- -- -- -- | 363 | | | | | | | | | | | | | | | | | | | | 364 | -- -- -- -- -- -- -- -- -- | 365 +--------------------------------------------------+ 367 Figure 4: NCG and external PCE 369 PCE has the capability to compute constrained paths between a source 370 and one or more destination(s), optionally providing the value of the 371 metrics associated to the computed path(s). Thus it can fit very 372 well in the horizontal query stage of CSO. A PCE MAY have further 373 capability to do multi-layer and/or inter-domain path computation 374 which can be further utilized. NCG which understands the vertical 375 query and the presence of applications constraints can break the 376 application request into suitable path computation request which PCE 377 understands. In this scenario, the PCE MAY have no knowledge of 378 applications and provide only network related metrics to the NCG: the 379 NCG (or the ACG for an application-centric model) is in charge of 380 correlating the network quotations with the application layer 381 information to achieve the global CSO objective. 383 With this architecture, NCG can request PCE different sets of 384 computation mode that are not currently supported by PCE. For 385 instance, NCG may request PCE a multi-destination and multi-source 386 path computation request. This scenario arises when there are many 387 possible Data Center choices for a given application request and 388 there could be multiple sources for this request. Multi-destination 389 with a single source (aka., anycast) is a default case for multi- 390 destination and multi-source path computation. 392 In addition, with this architecture, NCG may have different sets of 393 objectives and constraints than typical path computation requests. 394 For instance, multi-criteria objective functions that combine the 395 bandwidth requirement and latency may be very useful for some 396 applications. [PCE-SERVICE-AWARE] describes the extension to PCEP to 397 carry Latency, Latency-Variation and Loss as constraints for end to 398 end path computation. 400 In a Stateful PCE (refer [PCE-STATEFUL]), there is a strict 401 synchronization of the network states (in term of topology and 402 resource information), and the set of computed paths and reserved 403 resources in use in the network. In other words, the PCE utilizes 404 information from the TED as well as information about existing paths 405 (for example, TE LSPs) in the network when processing new requests. 406 Stateful PCE will be very important tool to achieve the goals of 407 cross stratum optimization as maintains the status of final path 408 selected after cross (application and network) optimization. 410 As Stateful PCE would keep both LSP ID and the application ID 411 associated with the LSP, it will make path computation more efficient 412 in terms of resource usage and computation time. Moreover, Stateful 413 PCE would have an accurate snapshot of network resource information 414 and as such it can increase adaptability to the changes. This may be 415 important for some application that requires a stringent performance 416 objective. 418 In conclusion - 420 o NCG can use the PCE to do path computation based on constrains 421 from multiple sources and destinations. 423 o Stateful PCE can help in maintaining the status of the final cross 424 optimized path. It can also help NCG in maintaining the 425 relationship of application request and setup path. In case of 426 any change of the path, the Stateful PCE and NCG and cooperate and 427 take suitable action. 429 4. Path Computation and Setup Procedure 431 Path computation flow is shown in Figure 5. 433 1. User for application would contact the application gateway ACG 434 with its requirements. 436 2. ACG would further query the NCG to obtain the underlying network 437 Status and quotations (offers) for the network connectivity 438 services. 440 3. NCG would break the vertical request into suitable horizontal 441 path computation request(s). 443 4. PCE would provide the result to NCG. 445 5. NCG would abstract the computation result and provide to ACG. 447 6. NCG and ACG would cooperate to finalize the path that needs to be 448 setup. 450 7. Note that that the final decision can be made either in ACG or 451 NCG depending on the mode of operation. With application centric 452 mode, minimal data center/IT resource information would flow from 453 ACG to NCG while ACG collects network abstracted information from 454 NCG to choose the optimal application-network resources. With 455 network centric mode, ACG would supply maximal data center/IT 456 resource information to NCG so that NCG in conjunction with PCE 457 would determine the optimal mixed set of application and network 458 resources. In the latter case, the PCE COULD support application 459 /IT- based constrained computation capability beyond network path 460 computation. This requires further PCE capabilities to receive 461 and process data center/IT resource information, possibly in 462 conjunction with network information. 464 +----------+ 1 +---------------------------------------+ 465 | |-------->| | 466 | User | | ACG | 467 | |<--------| | 468 +----------+ 6 +---------------------------------------+ 469 ^ | 470 | 2| 471 | | +----------+ 3 +----------+ 472 | +->| |--------->| | 473 | | NCG | | PCE | 474 +-----| |<---------| | 475 5 +----------+ 4 +----------+ 477 Figure 5: Path Computation Flow 479 In this section we would analyze the mechanisms to finally setup the 480 cross stratum optimized path. 482 4.1. Path Setup Using NMS 484 After ACG and NCG have decided the path that needs to be set, NCG can 485 send a request to NMS asking it relay the message to the head end LSR 486 (also a PCC) to setup the pre computed path. Once the path signaling 487 is completed and the LSP is setup, PCC should relay the status of the 488 LSP to the Stateful PCE. 490 In this mechanism we can reuse the existing NMS to establish the 491 path. Any updates or deletion of such path would be made via the 492 NMS. 494 Head end LSR (PCC) 'H' is always the owner of the path. 496 See Figure 6 for this scenario. 498 +----------+ +---------------------------------------+ 499 | |-------->| | 500 | User | | ACG | 501 | |<--------| | 502 +----------+ +---------------------------------------+ 503 ^ | 504 +-----------------+--+------------------------------------+ 505 |+----------+ | | +----------+ +----------+| 506 || | | +->| |--------->| || 507 || NMS | +-----| NCG | | PCE || 508 || |<----------| |<---------| || 509 |+----------+ +----------+ +----------+| 510 | | ^ | 511 | | +------------------------------------+ | 512 | | | Network Stratum | 513 | | -- -- -- -- -- -- -- -- -- | 514 | +----->|H | | | | | | | | | | | | | | | | | | 515 | -- -- -- -- -- -- -- -- -- | 516 +---------------------------------------------------------+ 518 Figure 6: Path Setup Using NMS 520 4.2. Path Setup Using a Network Control Plane 522 A network control plane (e.g. GMPLS) MAY be used to automatically 523 establish the cross optimized path between the selected end points. 524 This control plane MAY be triggered via - 526 o NCG to Control Plane: GMPLS UNI or other protocols 528 o Control Plane to Head end Router: GMPLS Control Channel Interface 529 (CCI). Suitable protocol extensions are needed to achieve this. 531 See Figure 7 for this scenario. 533 +----------+ +---------------------------------------+ 534 | |-------->| | 535 | User | | ACG | 536 | |<--------| | 537 +----------+ +---------------------------------------+ 538 ^ | 539 +-----------------+--+------------------------------------+ 540 |+----------+ | | +----------+ +----------+| 541 || GMPLS | | +->| |--------->| || 542 || Control | +-----| NCG | | PCE || 543 || plane |<----------| |<---------| || 544 |+----------+ +----------+ +----------+| 545 | | ^ | 546 | | +------------------------------------+ | 547 | | | Network Stratum | 548 | | -- -- -- -- -- -- -- -- -- | 549 | +----->|H | | | | | | | | | | | | | | | | | | 550 | -- -- -- -- -- -- -- -- -- | 551 +---------------------------------------------------------+ 553 Figure 7: Path Setup Using Centralized Control Plane 555 After cross optimization, ACG and NCG will select the suitable end 556 points, (the path is already calculated by PCE), this path is 557 conveyed to the head end LSR which signals the path and notify the 558 status to the Stateful PCE. Later NCG can send suitable message to 559 tear down the path. 561 Using centralized control plane can make the NCG responsible for the 562 LSP. Head end LSR signals and maintains the status but the 563 establishment and tear-down are initiated by the control plane. This 564 would have an obvious advantage in managing the setup paths. The 565 Stateful PCE will maintain the TED as well as the status of setup 566 LSP. NCG through centralized control plane can further setup/ 567 teardown/modify/re-optimize those paths. 569 4.3. Path Setup using PCE 571 A Stateful PCE extension MAY be developed to communicate the cross 572 optimized path to the head end LSR. Current PCEP protocol requires 573 PCC to trigger Path request and PCE to provide reply. Even in 574 Stateful PCE, PCC must delegate the LSP to a PCE, a PCE never 575 initiate path setup. An extension to PCEP protocol MAY let PCE 576 notify to PCC (Head end LSR) to establish the path. 578 NCG via PCE and PCEP protocol can establish and tear-down LSP as 579 shown in Figure 8. [PCE_INITIATED] is one such attempt to extend 580 PCEP. 582 +----------+ +---------------------------------------+ 583 | |-------->| | 584 | User | | ACG | 585 | |<--------| | 586 +----------+ +---------------------------------------+ 587 ^ | 588 +-----------------+--+------------------------------------+ 589 | | | +----------+ +----------+| 590 | | +->| |--------->| || 591 | | | NCG | | PCE || 592 | +-----| |<---------| || 593 | +----------+ +----------+| 594 | +---------------------------------------+ ^ | 595 | | +------------------------------------+ | 596 | | | Network Stratum | 597 | | -- -- -- -- -- -- -- -- -- | 598 | +->|H | | | | | | | | | | | | | | | | | | 599 | -- -- -- -- -- -- -- -- -- | 600 +---------------------------------------------------------+ 602 Figure 8: Path Setup using PCE 604 4.4. Path Setup Using a Software Defined Network controller 606 A logically centralized Software Defined Network (SDN) controller MAY 607 be used to properly configure in an automatic way the traffic 608 forwarding rules that allow the end to end communication across the 609 Network Stratum. 611 Figure 9 shows this scenario. 613 +----------+ +---------------------------------------+ 614 | |-------->| | 615 | User | | ACG | 616 | |<--------| | 617 +----------+ +---------------------------------------+ 618 ^ | 619 +-----------------+--+------------------------------------+ 620 | | | +----------+ +----------+| 621 | | +->| |--------->| || 622 | | | NCG | | PCE || 623 | +-----| |<---------| || 624 | +----------+ +----------+| 625 | | ^ | 626 | v | | 627 | +----------------------------+ | 628 | +-| SDN Controller |--+ | 629 | | +----------------------------+ | | 630 | | | | | | | | | | 631 | v v v v v v v v | 632 | -- -- -- -- -- -- -- -- | 633 | | | | | | | | | | | | | | | | | | 634 | -- -- -- -- -- -- -- -- | 635 | | 636 | Network Stratum | 637 | | 638 +---------------------------------------------------------+ 640 Figure 9: Path Setup using SDN 642 A direct interface between the SDN Controller and the PCE could be 643 present in the architecture shown in Figure 9. 645 As result of the interaction between ACG and NCG (including the PCE 646 processing), the NCG is able to instruct the SDN Controller to 647 populate a number of forwarding rules to the network devices for 648 building the end to end path. 650 5. Other Consideration 652 5.1. Inter-domain 654 5.1.1. One Application Domain with Multiple Network Domains 656 Underlying network connecting the datacenters MAYBE made up of 657 multiple domains (AS and Area). In this case an inter-domain path 658 computation is required. 660 +----------+ +---------------------------------------+ 661 | |-------->| | 662 | User | | ACG | 663 | |<--------| | 664 +----------+ +---------------------------------------+ 665 ^ | 666 | | 667 +--------------+ +--+--+------------------------------------+ 668 | +----------+| | | | +----------+ +----------+| 669 | | || | | +->| |--------->| || 670 | | PCE || | | | NCG | | PCE || 671 | | || | +-----| |<---------| || 672 | +----+-----+| | +----------+ +----+-----+| 673 | | | | | | 674 +-------+------+ +-----------------------------------+------+ 675 | | 676 | | 677 |<---------------pcep session----------------->| 678 | | 680 Figure 10: Multi-domain Scenario 682 [RFC5441] describes an inter-domain path computation with cooperating 683 PCEs which can be enhanced and utilized in CSO enabled path 684 computation. 686 5.1.2. Multiple Application Domains with Multiple Network Domains 688 Underlying network connecting the datacenters MAY be made up of 689 multiple domains (AS and Area) as well as applications domains and 690 ACG MAY be distributed. In such case multiple ACG and NCG will be 691 involved in cross optimizing. This needs to be analyzed further. 693 5.1.2.1. ACG talks to multiple NCGs 695 As shown in Figure 11, ACG where the request originates may 696 communicate with multiple NCG to get the network information from 697 multiple domains to be cross optimized. 699 Application stratum 700 +---------------------------+ +---------------------------+ 701 | | | | 702 | | | | 703 | | | | 704 | | | | 705 | | | | 706 | +----------------------+ | | +----------------------+ | 707 | | | | | | | | 708 +--+ ACG +-+ +--+ ACG +-+ 709 | | | | 710 +-+-+-------------+-+--+ +-------+-+------------+ 711 | | | +------------+ | | 712 | | +------------+ | | | 713 +-+-+--------+ +-----+ +-+-----+-+--+ +-----+ 714 +--+ +---+ +-+ +--+ +----+ ++ 715 | | NCG |---| | | | | NCG |----| || 716 | | |---| | | | | |----| || 717 | +------------+ | PCE | | | +------------+ | PCE || 718 | | | | | | || 719 | | |<+--+------------------->| || 720 | +-----+ | | +-----+| 721 |Domain 1 | |Domain 2 | 722 +---------------------------+ +---------------------------+ 723 Network Stratum 725 Figure 11: ACG talks to multiple NCG 727 5.1.2.2. ACG talks to the primary NCG, which talks to the other NCG of 728 different domains 730 As shown in Figure 12, ACG communicated only to the primary NCG, 731 which may gather network information from multiple NCG and then 732 communicate consolidated information to ACG. 734 Application stratum 735 +---------------------------+ +---------------------------+ 736 | | | | 737 | | | | 738 | | | | 739 | | | | 740 | | | | 741 | +----------------------+ | | +----------------------+ | 742 | | | | | | | | 743 +--+ ACG +-+ +--+ ACG +-+ 744 | | | | 745 +-+-+------------------+ +-------+-+------------+ 746 | | | | 747 | | | | 748 +-+-+--------+ +-----+ +-------+-+--+ +-----+ 749 +--+ +---+ +-+ +--+ +----+ ++ 750 | | NCG |---| | | | | NCG |----| || 751 | | |---| | | | | |----| || 752 | +------+-----+ | PCE | | | +---+--------+ | PCE || 753 | | | | | | | | || 754 | | | |<+--+------+------------>| || 755 | | +-----+ | | | +-----+| 756 |Domain 1 | | |Domain|2 | 757 +---------+-----------------+ +------+--------------------+ 758 | | Network Stratum 759 | | 760 |<------------------------->| 761 | | 763 Figure 12: Primary NCG talks to other NCG 765 5.1.3. Federation of SDN domains 767 In this case, the Data Centers are federated building a community 768 cloud. In each Data Center, the connection to the network stratum 769 that interconnects the Data Center federation is done by means of one 770 or more devices controllable through an SDN controller particular for 771 that Data Center. 773 The NCG, then, interacts with a number of separated SDN controllers, 774 orchestrating their operation in order to perform the service 775 requested by the ACG in an optimized way. 777 Figure 13 shows this scenario. 779 +----------+ +---------------------------------------+ 780 | |-------->| | 781 | User | | ACG | 782 | |<--------| | 783 +----------+ +---------------------------------------+ 784 | ^ 785 | | 786 +----------+--+-------------------------+ 787 | | | | 788 | v | | 789 | +----------+ +----------+| 790 | | |-------->| || 791 | | NCG | | PCE || 792 | | |<--------| || 793 | +----------+ +----------+| 794 | | ^ | ^ | 795 | | | | | | 796 +-------+-+----+-+----------------------+ 797 | | | | 798 +-------------+ | | +-------------+ 799 | +-------------+ +-------------+ | 800 | | | | 801 v | v | 802 +--------------------+ +--------------------+ 803 +- | SDN Controller DC1 | . . . | SDN Controller DCN | -+ 804 | +--------------------+ +--------------------+ | 805 | | 806 | Federated Data Centers | 807 +-------------------------------------------------------------+ 809 Figure 13: NCG orchestration of separated SDN domains 811 5.2. Bottleneck 813 In optical networks all PCE messages are sent over control channel, 814 in Stateful PCE cases its observed that in case of a major link or 815 node failure lot of PCEP messages are sent from all PCC to PCE. This 816 use lot of bandwidth of the control channel. 818 PCE MAY become a common point of failure and bottleneck. PCE/NCG/ACG 819 failure as well as the link-failure disrupting connectivity could be 820 highly disruptive to the system. 822 The solution should focus on reducing such bottleneck. 824 6. IANA Considerations 826 TBD 828 7. Security Considerations 830 TBD 832 8. Manageability Considerations 834 TBD 836 9. Acknowledgements 838 Part of the work in this document has been funded by the European 839 Community's Seventh Framework Programme projects XIFI (L.M. Contreras 840 and O. Gonzalez), under grant agreement n. 604590, and GEYSERS (N. 841 Ciulli and L.M. Contreras), under grant agreement n. 248657. 843 10. References 845 10.1. Normative References 847 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 848 Requirement Levels", BCP 14, RFC 2119, March 1997. 850 10.2. Informative References 852 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 853 Element (PCE)-Based Architecture", RFC 4655, August 2006. 855 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element 856 (PCE) Communication Protocol (PCEP)", RFC 5440, March 857 2009. 859 [RFC5441] Vasseur, JP., Zhang, R., Bitar, N., and JL. Le Roux, "A 860 Backward-Recursive PCE-Based Computation (BRPC) Procedure 861 to Compute Shortest Constrained Inter-Domain Traffic 862 Engineering Label Switched Paths", RFC 5441, April 2009. 864 [CSO-DATACNTR] 865 Lee, Y., Bernstein, G., So, N., Kim, T., Shiomoto, K., and 866 O. Gonzalez-de-Dios, "Research Proposal for Cross Stratum 867 Optimization (CSO) between Data Centers and Networks. 868 (draft-lee-cross-stratum-optimization-datacenter-00)", 869 March 2011. 871 [CSO-PROBLEM] 872 Lee, Y., Bernstein, G., So, N., Hares, S., Xia, F., 873 Shiomoto, K., and O. Gonzalez-de-Dios, "Problem Statement 874 for Cross-Layer Optimization. (draft-lee-cross-layer- 875 optimization-problem-02)", January 2011. 877 [NS-QUERY] 878 Lee, Y., Bernstein, G., So, N., McDysan, D., Kim, T., 879 Shiomoto, K., and O. Gonzalez-de-Dios, "Problem Statement 880 for Network Stratum Query. (draft-lee-network-stratum- 881 query-problem-02)", April 2011. 883 [CSO-PCE-REQT] 884 Tovar, A., Contreras, L., Landi, G., and N. Ciulli, "Path 885 Computation Requirements for Cross-Stratum-Optimization. 886 (draft-tovar-cso-path-computation-requirements-00)", 887 October 2011. 889 [PCE-SERVICE-AWARE] 890 Dhody, D., Manral, V., Ali, Z., Swallow, G., and K. 891 Kumaki, "Extensions to the Path Computation Element 892 Communication Protocol (PCEP) to compute service aware 893 Label Switched Path (LSP). (draft-ietf-pce-pcep-service- 894 aware-01)", July 2013. 896 [PCE-STATEFUL] 897 Crabbe, E., Medved, J., Varga, R., and I. Minei, "PCEP 898 Extensions for Stateful PCE. (draft-ietf-pce-stateful- 899 pce-06)", August 2013. 901 [ALTO-APPNET] 902 Lee, Y., Bernstein, G., Varga, T., Madhavan, S., and D. 903 Dhody, "ALTO Extensions to Support Application and Network 904 Resource Information Exchange for High Bandwidth 905 Applications. (draft-lee-alto-app-net-info-exchange-02)", 906 July 2013. 908 [PCE_INITIATED] 909 Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 910 Extensions for PCE-initiated LSP Setup in a Stateful PCE 911 Model. (draft-crabbe-pce-pce-initiated-lsp-02)", July 912 2013. 914 Authors' Addresses 915 Dhruv Dhody 916 Huawei Technologies 917 Leela Palace 918 Bangalore, Karnataka 560008 919 INDIA 921 EMail: dhruv.dhody@huawei.com 923 Young Lee 924 Huawei Technologies 925 1700 Alma Drive, Suite 500 926 Plano, TX 75075 927 USA 929 EMail: leeyoung@huawei.com 931 Luis M. Contreras 932 Telefonica I+D 933 Ronda de la Comunicacion, s/n 934 Sur-3 building, 3rd floor 935 Madrid 28050 936 Spain 938 EMail: lmcm@tid.es 940 Oscar Gonzalez de Dios 941 Telefonica I+D 942 Don Ramon de la Cruz, 82 943 Madrid 28006 944 Spain 946 EMail: ogondio@tid.es 948 Nicola Ciulli 949 Nextworks 951 EMail: n.ciulli@nextworks.it