idnits 2.17.1 draft-dhody-actn-poi-use-case-04.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 a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 374: '... optical domains MAY be provided to th...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 16, 2015) is 3298 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ACTN BOF D. Dhody 3 Internet-Draft X. Zhang 4 Intended status: Informational Huawei Technologies 5 Expires: October 18, 2015 O. Gonzalez de Dios 6 Telefonica 7 D. Ceccarelli 8 Ericsson 9 B. Yoon 10 ETRI 11 April 16, 2015 13 Packet Optical Integration (POI) Use Cases for Abstraction and Control 14 of Transport Networks (ACTN) 15 draft-dhody-actn-poi-use-case-04 17 Abstract 19 This document describes the Abstraction and Control of Transport 20 Networks (ACTN) use cases related to Packet and Optical Integration 21 (POI), that may be potentially deployed in various transport networks 22 and apply to different applications. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on October 18, 2015. 41 Copyright Notice 43 Copyright (c) 2015 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. POI Scenario . . . . . . . . . . . . . . . . . . . . . . 4 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 3. Packet Optical Integration . . . . . . . . . . . . . . . . . 7 62 3.1. Traffic Planning, Monitoring and Automatic Network 63 Adjustments . . . . . . . . . . . . . . . . . . . . . . . 7 64 3.1.1. Automated Congestion Management . . . . . . . . . . . 8 65 3.2. Protection and Restoration Synergy . . . . . . . . . . . 8 66 3.3. Service Awareness . . . . . . . . . . . . . . . . . . . . 9 67 3.4. Coordination between Multiple Network Domains . . . . . . 9 68 4. Typical Workflow . . . . . . . . . . . . . . . . . . . . . . 10 69 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 70 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 71 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 72 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 73 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 74 8.2. Informative References . . . . . . . . . . . . . . . . . 13 75 Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 14 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 78 1. Introduction 80 Network operators build and operate multi-layered multi-domain 81 networks and these domains may be technology, administrative or 82 vendor specific (vendor islands). Interoperability for dealing with 83 different domains is a perpetual problem for operators. Due to these 84 issues, new service introduction, often requiring connections that 85 traverse multiple domains, need significant planning, and several 86 manual operations to interface different vendor equipment and 87 technology accross IP and Optical layers. 89 The aim of Abstraction and Control of Transport Networks (ACTN) is to 90 facilitate virtual network operation, creation of a virtualized 91 environment allowing operators to view and control multi-subnet 92 multi-technology networks into a single virtualized network. This 93 will accelerate rapid service deployment of new services, including 94 more dynamic and elastic services, and improve overall network 95 operations and scaling of existing services. 97 [ACTN-REQ] describes high-level ACTN requirements some of which are 98 derived from the usecases described in this document. 100 [ACTN-FWK] describes a business model of ACTN, comprising of 101 customers, service providers and network providers. This separates 102 the network operations on physical network from the business needs 103 (based on virtual network). It further describes the architecture 104 model for ACTN including the entities (Customer Network 105 Controller(CNC), Mult-domain Service Coordinator(MDSC), and Physical 106 Network Controller(PNC)) thier interfaces. 108 Discussion with operators has highlighted a need for virtual network 109 operation based on the abstraction of underlying technology and 110 vendor domains. This would be used for a variety of key use cases, 111 including: 113 o Physical network infrastructure providers who want to build 114 virtual network operations infrastructure via standards-based 115 interfaces that facilitates automation and operation of multiple 116 virtual networks for both internal and external trust domains. 118 o Data Center operators that need to lease facility from a number of 119 physical network infrastructure providers to offer their global 120 data center applications and services. As they face multi-domain 121 and diverse transport technology, interoperability based on 122 standard-based abstraction will enable dynamic and flexible 123 applications and services. 125 The transport networks are in an unique position to embrace the 126 concepts of software defined networking (SDN) because of the existing 127 separation in control and forwarding plane via GMPLS/ASON. The path 128 computation element (PCE) [RFC4655] and its stateful extension 129 [STATEFUL-PCE] can further provide a central control over the 130 resources. Also [STATEFUL-PCE-INITIATED] provides capability to 131 initiate and delete LSP dynamically. ACTN is focused on building 132 over the existing blocks by adding programmability, access and 133 control over abstract virtual topologies. [ACTN-PROBLEM] and 134 [ACTN-FWK] provide detailed information regarding this work. This 135 document focuses on the Packet and Optical Integration (POI) use 136 cases of ACTN. We refer to POI as packet over any connection- 137 oriented transport technologies such as MPLS-TE, MPLS-TP, OTN or 138 WSON. 140 It is preferable to coordinate network resource control and 141 utilization rather than controlling and optimizing resources at each 142 network layer (packet and optical transport network) independently. 143 This facilitates network efficiency and network automation. 145 In a multi-layer network via client and server networking roles, 146 Label Switched Paths (LSPs) in a server (lower) layer are used to 147 carry client (higher) layer LSPs across the server (lower) layer 148 network. POI in a distributed control plane environment may be 149 achieved by some of the existing mechanism as specified in [RFC4208] 150 and [RFC5623]. This document explores the POI use cases of ACTN to 151 help provide programmable network services like orchestration, access 152 to abstract topology and control over the resources. 154 Increasingly there is a need for packet and optical transport 155 networks to work together to provide accelerated services. Transport 156 networks can provide useful information to the packet network 157 allowing it to make intelligent decisions and control its allocated 158 resources. 160 1.1. POI Scenario 162 This section explores some typical scenario for packet and optical 163 integration (POI). These include, but not limited to, a single 164 administrative domain as well as Carriers-of-Carrier case. 166 Figure 1 shows a single administrative domain comprising of both 167 Packet and Optical transport networks. A POI coordinator would help 168 build and operate a multi-layered multi-domain allowing operators to 169 view and control a single virtualized network. 171 +------------+ 172 +------------------+ POI | 173 | |Orchestrator| 174 | +-----+------+ (MDSC) 175 +-v---+ | 176 | | | 177 +-----+ +--v--+ 178 Packet | | 179 Control +-----+ 180 (PNC) Optical Control (PNC) 181 +------------+ +---------------------------+ +--------------+ 182 | | | | | | 183 | +-+ | | +-+ +-+ | | +-+ +-+ | 184 | |R| |***|O| |O|********|R| |R| | 185 | +-+ +-+ |*| +-+ +-+ +-+ | | +-+ +-+ | 186 | |R|*****| |O| | | | 187 | +-+*****| +-+ | | | 188 | +-+ |*| +-+ +-+ +-+ | | +-+ | 189 | |R| |*****|O| |O| |O|*******|R| | 190 | +-+ | | +-+ +-+ +-+ | | +-+ | 191 | | | | | | 192 +------------+ +---------------------------+ +--------------+ 193 Packet Optical Transport Packet 194 Network Network Network 196 Figure 1: POI for single adminstration 198 Figure 2 shows a Carriers-of-Carrier case, where an optical transport 199 infrastructure provider provides ACTN service to the ISP. 201 +-------------+ 202 | ISP | 203 | Controler | (CNC) 204 +------------+------+------+---------------+ 205 | | | 206 | | | 207 | V | 208 | +------------+ | 209 | | MDSC | | 210 | | | | 211 | +------------+ | 212 | | | 213 | | | 214 | V | 215 | +------------+ | 216 +-+-------+ | PNC | +--------+-+ 217 | -- | | | | -- | 218 | | | | +------------+ || | | 219 | -- | | -- -- | 220 | -- | +-----------------+ | -- | | | 221 | | |**** | -- -- | ***| | -- | 222 | -- |*****| | | |**** | -- | 223 +---------+ | -- -- | +----------+ 224 ISP | -- | ISP 225 (Packet) | | | -- | (Packet) 226 | -- | | | 227 | -- | 228 +-----------------+ 229 Infrastructre 230 Provider 231 (optical) 233 Figure 2: POI for Carriers-of-Carrier 235 2. Terminology 237 The following terms are as defined in [ACTN-FWK]: 239 o CNC:Customer Network Controller 241 o PNC:Physical Network Controller 243 o MDSC:Multi-domain Service Coordinator 245 The following terminology is used in this document. 247 ACTN: Abstraction and Control of Transport Networks. 249 PCE: Path Computation Element. An entity (component, application, 250 or network node) that is capable of computing a network path or 251 route based on a network graph and applying computational 252 constraints. 254 POI: Packet and Optical Integration 256 VNTM: Virtual Network Topology Manager 258 3. Packet Optical Integration 260 Connections (or tunnels) formed across the optical transport network, 261 can be used as virtual TE links in the packet network. The 262 relationship is reduced to determining which tunnels to set up, how 263 to trigger them, how to route them, and what capacity to assign them. 264 As the demands in the packet network vary, these tunnels may need to 265 be modified. 267 One possible way to envision POI is via considering packet network as 268 customer i.e. an entity in packet network - (maybe a Path Computation 269 Element (PCE), Virtual Network Topology Manager (VNTM) [RFC5623], 270 Controller etc..) should be aware of the abstract topology of the 271 optical transport network. This entity is the customer network 272 controller (CNC) as per [ACTN-FWK] which interacts with MDSC. This 273 is shown in Figure 2. Another way would be to consider Packet and 274 Optical transport networks as domains and a POI coordinator (MDSC) to 275 help build and operate a multi-layered multi-domain network allowing 276 operators to view and control a single virtualized network as shown 277 in Figure 1. 279 In either case, the abstract topology may consist of established 280 tunnels in optical transport network or ones that can be created on 281 demand. The level of abstraction is dependent on various management, 282 security and policy considerations. This abstract topology 283 information in the packet network can be utilized in various cases, 284 as detailed in the following sections. 286 3.1. Traffic Planning, Monitoring and Automatic Network Adjustments 288 Currently there is a schism between network planning for packet and 289 optical transport networks. Sometimes these networks are 290 administered, operated and planned independently even when they are a 291 part of a single trusted domain. Any change in traffic requirements 292 requires long business process to make changes in the network. In 293 dynamic networks this is no longer acceptable. 295 A unified Packet+Optical traffic planning tool can be developed which 296 uses the traffic demand matrix to plan the optical transport network. 298 Further based on traffic demand changes, historical data, traffic 299 prediction and monitoring, changes should be made to the optical 300 transport network. An access to abstract topology of the optical 301 transport network based on established and potential (on-demand) 302 tunnels in optical transport network can provide mechanism to handle 303 this. 305 Further optical bypass may be established automatically to offload 306 the continuous changing traffic to optical transport network allowing 307 streamlined business process between packet and optical transport 308 networks. 310 3.1.1. Automated Congestion Management 312 Congestion management and synergized network optimization for packet 313 and optical transport networks can eliminate the need for overbooking 314 of optical transport networks as dumb pipes. Application could be 315 written that provide automated congestion management and network 316 optimization. Automated congestion management recognizes prolonged 317 congestion in the network and works with the controllers to add 318 bandwidth at an optical transport layer, to alleviate the congestion, 319 or make changes in the packet layer to reroute traffic around the 320 congestion. 322 For such applications there is a clear need for an abstract network 323 topology of optical transport layer, further there is also a need for 324 a synergy of cost and SLA across optical and packet networks. 326 3.2. Protection and Restoration Synergy 328 The protection and restoration are usually handled individually in 329 Packet and optical layer. There is a need for synergy and optimized 330 handling of protection of resources across layers. A lot more 331 resources in the optical transport network are booked for backup then 332 actually required since there is a lack of coordination between 333 packet and optical layers. The access to abstract graph of optical 334 transport network with information pertaining to backup path 335 information can help the packet network to handle protection, shared 336 risk, fault restoration in an optimized way. Informing the packet 337 network about both working and protection path which are either 338 already established, or potential path can be useful. 340 A significant improvements in overall network availability that can 341 be achieved by using optical transport shared-risk link group (SRLG) 342 information to guide packet network decisions; for example, to avoid 343 or minimize common SRLGs for the main (working) path and the loop 344 free alternative or traffic engineered fast reroute (LFA/TE FRR) 345 back-up path. Shared risk information need to be synergized between 346 the packet and optical. A mechanism to provide abstracted SRLG 347 information can help the packet network consider this information 348 while handling protection and restoration. 350 3.3. Service Awareness 352 In certain networks like financial information network (stock/ 353 commodity trading) and enterprises using cloud based applications, 354 Latency (delay), Latency-Variation (jitter), Packet Loss and 355 Bandwidth Utilization are associated with the SLA. These SLAs must 356 be synergized across packet and optical transport networks. Network 357 optimization evaluates network resource usage at all layers and 358 recommends or executes service path changes while ensuring SLA 359 compliance. It thus makes more effective use of the network, and 360 relieves current or potential congestion. 362 The main economic benefits of ACTN arise from its ability to maintain 363 the SLA of the services at reduced overall network cost considering 364 both packet and optical transport network. Operational benefits of 365 the ACTN also stem from greater flexibility in handling dynamic 366 traffic such as demand uncertainty or variations over time, or 367 optimization based on cost or latency, or improved handling of 368 catastrophic failures. 370 3.4. Coordination between Multiple Network Domains 372 In some deployments, optical transport network may further be divided 373 into multiple domains, an abstracted topology comprising of multiple 374 optical domains MAY be provided to the packet network. A Seamless 375 aggregation and orchestration across multiple optical transport 376 domains is achieved via the MDSC, a great help in such deployments. 378 Another interesting deployment involves multiple packet network 379 domains. There exist scenarios where the topology provided to the 380 packet network domains may be different based on the initial demand 381 matrix as well as, management, security and policy considerations. 383 The ACTN framework as described in [ACTN-FWK] should support the 384 aggregation and orchestration across network domains and layers. 386 Further Figure 3 shows a multi-domain scenario where multiple PNC 387 (each controlling a packet or optical domain) and a MDSC coordinating 388 among them and providing a consolidated view. 390 +-------------------------+ 391 | MDSC | 392 | | 393 +-------------------------+ 394 * 395 +------------+---------+--+ * +-----------+---------+--+ 396 | +---------+ | * | +---------+ | 397 | | PNC ************************* PNC | | 398 | +---------+---------+ | * | +---------+---------+ | 399 | | | | * | | | | 400 | | | | * | | | | 401 | | | | * | | | | 402 | | Packet | | * | | Packet | | 403 | +-------------------+ | * | +-------------------+ | 404 | | * | | 405 | | * | | 406 | | * | | 407 | | * | | 408 | | * | | 409 | +---------+ | * | +---------+ | 410 | | PNC ************************* PNC | | 411 | +---------+---------+ | | +---------+---------+ | 412 | | | | | | | | 413 | | | | | | | | 414 | | | | | | | | 415 | | Optical | | | | Optical | | 416 | +-------------------+ | | +-------------------+ | 417 +---+-------------------+-+ +--+-------------------+-+ 419 Domain 1 Domain 2 421 Figure 3: Coordination between Multiple Network Domains 423 4. Typical Workflow 425 Consider a two-layer network where the higher-layer network is a 426 packet-based IP/MPLS or GMPLS network and the lower-layer network is 427 a GMPLS-controlled optical network both under a common administrative 428 control. 430 The PNC in both layers are under a common MDSC that coordinates 431 between the two layers. And this multi-layer network is used to 432 interconnect DCs, where the DC controller (customer network 433 controller - CNC) takes charge as shown in Figure 4. 435 Data Center 436 ***** Controller 437 -------------------------------------*CNC*------------- 438 | ***** | 439 | | Multi-layer | 440 | v Coordinator | 441 | ****** | 442 | *MDSC*-- | 443 Data | ****** | | 444 Center | | | 445 +----+ | ***** | +----+ | 446 | DC1|<- *PNC*<- | DC3|<- 447 +----+ | ***** | +----+ | 448 .....|.. Packet | .... | 449 +----+ | . +-----------------------------------+ | .+----+ | 450 | DC2|<- .. /R R R R..../...|..| DC4|<- 451 +----+ / R R / | +----+ 452 ........./....R . R . R R../.....|..... 453 +-----------------------------------+ | 454 Packet . . . . . . | 455 Layer . . . . . . | 456 . . . . . . ***** | 457 . . . . . . *PNC*<- 458 . . . . . . ***** Optical 459 +-----------------------------------+ 460 / O . O . O . O O / 461 / O . O O / 462 Optical / O O O O O / 463 Layer +-----------------------------------+ 465 Figure 4: Typical Workflow 467 Data centre controller (as Customer Network Controller) interfaces 468 the data centre application stratum, it understands multiple DC 469 application requirements and their service needs. DC Controller 470 provides its traffic demand matrix that describes bandwidth 471 requirements and other optional QoS parameters (e.g., latency, 472 diversity requirement, etc.) for each pair of inter-DC connections. 473 The MDSC (multi-layer coordinator) sits between the DC controller 474 (CNC - the one issuing connectivity requests) and the physical 475 network controllers (the one managing the resources). In this case 476 each layer has its own PNC managing the resources in each layer with 477 MDSC acting as a multi-layer coordinator. The PNC is in charge of 478 configuring the network elements, monitoring the physical topology of 479 the network and passing it, either raw or abstracted, to the MDSC. 481 MDSC with the help of PNC(s) coordinates network resource control and 482 utilization facilitating network efficiency and network automation. 483 The MDSC are also responsible for the abstract topology and the level 484 of abstraction, which facilitate various DC usecases like VM 485 Migrations, global load balancing among geographically distributed 486 DCs, Business continuity and disaster recovery etc using the ACTN 487 framework in an elastic and dynamic and way, improving overall 488 network operations and scaling. 490 Based on the Data centre controller's (acting as CNC) requests for 491 virtual network paths, the MDSC mediates with the PNCs and maps these 492 'virtual' request to inter-layer coordinated path computation and 493 provisioning requests in the 'physical' domain to the PNC. Thus MDSC 494 acts as a multi-layer coordinator both in respect to multi-layer end 495 to end optimized path computation as well as multi-layer signaling 496 and provisioning. The path computation and abstract topology 497 creation would be based on the guidelines set by the CNC including 498 the optimization criteria, traffic profile, policy etc. 500 In case the PNC could not fulfill the desired request from MDSC and 501 indirectly from DC controller, there should be a feedback loop to the 502 MDSC so that suitable actions including path recalculation and 503 signaling, negotiation of parameters and attributes with DC 504 controller etc can be undertaken. Thus MDSC effectively arbitrate 505 between the customers (DC) and the existing network (PNC) in this 506 example. 508 5. Security Considerations 510 TBD. 512 6. IANA Considerations 514 None, this is an informational document. 516 7. Acknowledgments 518 8. References 520 8.1. Normative References 522 [ACTN-FWK] 523 Ceccarelli, D. and Y. Lee, "Framework for Abstraction and 524 Control of Transport Networks (draft-ceccarelli-actn- 525 framework)", March 2015. 527 [ACTN-REQ] 528 Lee, Y., Dhody, D., Belotti, S., Pithewan, K., and D. 529 Ceccarelli, "Requirements for Abstraction and Control of 530 Transport Networks (draft-lee-teas-actn-requirements)", 531 April 2015. 533 8.2. Informative References 535 [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, 536 "Generalized Multiprotocol Label Switching (GMPLS) User- 537 Network Interface (UNI): Resource ReserVation Protocol- 538 Traffic Engineering (RSVP-TE) Support for the Overlay 539 Model", RFC 4208, October 2005. 541 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 542 Element (PCE)-Based Architecture", RFC 4655, August 2006. 544 [RFC5623] Oki, E., Takeda, T., Le Roux, JL., and A. Farrel, 545 "Framework for PCE-Based Inter-Layer MPLS and GMPLS 546 Traffic Engineering", RFC 5623, September 2009. 548 [STATEFUL-PCE] 549 Crabbe, E., Medved, J., Minei, I., and R. Varga, "PCEP 550 Extensions for Stateful PCE [draft-ietf-pce-stateful- 551 pce]", October 2014. 553 [STATEFUL-PCE-INITIATED] 554 Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 555 Extensions for PCE-initiated LSP Setup in a Stateful PCE 556 Model [draft-ietf-pce-pce-initiated-lsp]", October 2014. 558 [ACTN-PROBLEM] 559 Lee, Y., King, D., Boucadair, M., Jing, R., and L. 560 Contreras Murillo, "Problem Statement for Abstraction and 561 Control of Transport Networks (draft-leeking-actn-problem- 562 statement)", September 2014. 564 Appendix A. Contributor Addresses 566 Udayasree Palle 567 Huawei Technologies 568 Divyashree Techno Park, Whitefield 569 Bangalore, Karnataka 560037 570 India 572 EMail: udayasree.palle@huawei.com 574 Authors' Addresses 576 Dhruv Dhody 577 Huawei Technologies 578 Divyashree Techno Park, Whitefield 579 Bangalore, Karnataka 560037 580 India 582 EMail: dhruv.ietf@gmail.com 584 Xian Zhang 585 Huawei Technologies 586 Bantian, Longgang District 587 Shenzhen, Guangdong 518129 588 P.R.China 590 EMail: zhang.xian@huawei.com 592 Oscar Gonzalez de Dios 593 Telefonica 594 Spain 596 EMail: ogondio@tid.es 598 Daniele Ceccarelli 599 Ericsson 600 Via E. Melen 77, Genova - Erzelli 601 Italy 603 EMail: daniele.ceccarelli@ericsson.com 604 Bin-Yeong Yoon 605 ETRI 606 South Korea 608 EMail: byyun@etri.re.kr