idnits 2.17.1 draft-dhody-actn-poi-use-case-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- 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 370: '... 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 (October 14, 2014) is 3479 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: April 17, 2015 O. Gonzalez de Dios 6 Telefonica 7 D. Ceccarelli 8 Ericsson 9 B. Yoon 10 ETRI 11 October 14, 2014 13 Packet Optical Integration (POI) Use Cases for Abstraction and Control 14 of Transport Networks (ACTN) 15 draft-dhody-actn-poi-use-case-03 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 April 17, 2015. 41 Copyright Notice 43 Copyright (c) 2014 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 77 1. Introduction 79 Network operators build and operate multi-layered multi-domain 80 networks and these domains may be technology, administrative or 81 vendor specific (vendor islands). Interoperability for dealing with 82 different domains is a perpetual problem for operators. Due to these 83 issues, new service introduction, often requiring connections that 84 traverse multiple domains, need significant planning, and several 85 manual operations to interface different vendor equipment and 86 technology accross IP and Optical layers. 88 The aim of Abstraction and Control of Transport Networks (ACTN) is to 89 facilitate virtual network operation, creation of a virtualized 90 environment allowing operators to view and control multi-subnet 91 multi-technology networks into a single virtualized network. This 92 will accelerate rapid service deployment of new services, including 93 more dynamic and elastic services, and improve overall network 94 operations and scaling of existing services. 96 [ACTN-FWK] describes a business model of ACTN, comprising of 97 customers, service providers and network providers. This separates 98 the network operations on physical network from the business needs 99 (based on virtual network). It further describes the architecture 100 model for ACTN including the entities (Customer Network 101 Controller(CNC), Virtual Network Controller(VNC), and Physical 102 Network Controller(PNC)) thier interfaces. 104 Discussion with operators has highlighted a need for virtual network 105 operation based on the abstraction of underlying technology and 106 vendor domains. This would be used for a variety of key use cases, 107 including: 109 o Physical network infrastructure providers who want to build 110 virtual network operations infrastructure via standards-based 111 interfaces that facilitates automation and operation of multiple 112 virtual networks for both internal and external trust domains. 114 o Data Center operators that need to lease facility from a number of 115 physical network infrastructure providers to offer their global 116 data center applications and services. As they face multi-domain 117 and diverse transport technology, interoperability based on 118 standard-based abstraction will enable dynamic and flexible 119 applications and services. 121 The transport networks are in an unique position to embrace the 122 concepts of software defined networking (SDN) because of the existing 123 separation in control and forwarding plane via GMPLS/ASON. The path 124 computation element (PCE) [RFC4655] and its stateful extension 125 [STATEFUL-PCE] can further provide a central control over the 126 resources. Also [STATEFUL-PCE-INITIATED] provides capability to 127 initiate and delete LSP dynamically. ACTN is focused on building 128 over the existing blocks by adding programmability, access and 129 control over abstract virtual topologies. [ACTN-PROBLEM] and 130 [ACTN-FWK] provide detailed information regarding this work. This 131 document focuses on the Packet and Optical Integration (POI) use 132 cases of ACTN. We refer to POI as packet over any connection- 133 oriented transport technologies such as MPLS-TE, MPLS-TP, OTN or 134 WSON. 136 It is preferable to coordinate network resource control and 137 utilization rather than controlling and optimizing resources at each 138 network layer (packet and optical transport network) independently. 139 This facilitates network efficiency and network automation. 141 In a multi-layer network via client and server networking roles, 142 Label Switched Paths (LSPs) in a server (lower) layer are used to 143 carry client (higher) layer LSPs across the server (lower) layer 144 network. POI in a distributed control plane environment may be 145 achieved by some of the existing mechanism as specified in [RFC4208] 146 and [RFC5623]. This document explores the POI use cases of ACTN to 147 help provide programmable network services like orchestration, access 148 to abstract topology and control over the resources. 150 Increasingly there is a need for packet and optical transport 151 networks to work together to provide accelerated services. Transport 152 networks can provide useful information to the packet network 153 allowing it to make intelligent decisions and control its allocated 154 resources. 156 1.1. POI Scenario 158 This section explores some typical scenario for packet and optical 159 integration (POI). These include, but not limited to, a single 160 administrative domain as well as Carriers-of-Carrier case. 162 Figure 1 shows a single administrative domain comprising of both 163 Packet and Optical transport networks. A POI coordinator would help 164 build and operate a multi-layered multi-domain allowing operators to 165 view and control a single virtualized network. 167 +------------+ 168 +------------------+ POI | 169 | |Orchestrator| 170 | +-----+------+ (VNC) 171 +-v---+ | 172 | | | 173 +-----+ +--v--+ 174 Packet | | 175 Control +-----+ 176 (PNC) Optical Control (PNC) 177 +------------+ +---------------------------+ +--------------+ 178 | | | | | | 179 | +-+ | | +-+ +-+ | | +-+ +-+ | 180 | |R| |***|O| |O|********|R| |R| | 181 | +-+ +-+ |*| +-+ +-+ +-+ | | +-+ +-+ | 182 | |R|*****| |O| | | | 183 | +-+*****| +-+ | | | 184 | +-+ |*| +-+ +-+ +-+ | | +-+ | 185 | |R| |*****|O| |O| |O|*******|R| | 186 | +-+ | | +-+ +-+ +-+ | | +-+ | 187 | | | | | | 188 +------------+ +---------------------------+ +--------------+ 189 Packet Optical Transport Packet 190 Network Network Network 192 Figure 1: POI for single adminstration 194 Figure 2 shows a Carriers-of-Carrier case, where an optical transport 195 infrastructure provider provides ACTN service to the ISP. 197 +-------------+ 198 | ISP | 199 | Controler | (CNC) 200 +------------+------+------+---------------+ 201 | | | 202 | | | 203 | V | 204 | +------------+ | 205 | | VNC | | 206 | | | | 207 | +------------+ | 208 | | | 209 | | | 210 | V | 211 | +------------+ | 212 +-+-------+ | PNC | +--------+-+ 213 | -- | | | | -- | 214 | | | | +------------+ || | | 215 | -- | | -- -- | 216 | -- | +-----------------+ | -- | | | 217 | | |**** | -- -- | ***| | -- | 218 | -- |*****| | | |**** | -- | 219 +---------+ | -- -- | +----------+ 220 ISP | -- | ISP 221 (Packet) | | | -- | (Packet) 222 | -- | | | 223 | -- | 224 +-----------------+ 225 Infrastructre 226 Provider 227 (optical) 229 Figure 2: POI for Carriers-of-Carrier 231 2. Terminology 233 The following terms are as defined in [ACTN-FWK]: 235 o CNC:Customer Network Controller 237 o PNC:Physical Network Controller 239 o VNC:Virtual Network Controller 241 The following terminology is used in this document. 243 ACTN: Abstraction and Control of Transport Networks. 245 PCE: Path Computation Element. An entity (component, application, 246 or network node) that is capable of computing a network path or 247 route based on a network graph and applying computational 248 constraints. 250 POI: Packet and Optical Integration 252 VNTM: Virtual Network Topology Manager 254 3. Packet Optical Integration 256 Connections (or tunnels) formed across the optical transport network, 257 can be used as virtual TE links in the packet network. The 258 relationship is reduced to determining which tunnels to set up, how 259 to trigger them, how to route them, and what capacity to assign them. 260 As the demands in the packet network vary, these tunnels may need to 261 be modified. 263 One possible way to envision POI is via considering packet network as 264 customer i.e. an entity in packet network - (maybe a Path Computation 265 Element (PCE), Virtual Network Topology Manager (VNTM) [RFC5623], 266 Controller etc..) should be aware of the abstract topology of the 267 optical transport network. This entity is the customer network 268 controller (CNC) as per [ACTN-FWK] which interacts with Virtual 269 Network Controller (VNC). This is shown in Figure 2. Another way 270 would be to consider Packet and Optical transport networks as domains 271 and a POI coordinator (VNC) to help build and operate a multi-layered 272 multi-domain network allowing operators to view and control a single 273 virtualized network as shown in Figure 1. 275 In either case, the abstract topology may consist of established 276 tunnels in optical transport network or ones that can be created on 277 demand. The level of abstraction is dependent on various management, 278 security and policy considerations. This abstract topology 279 information in the packet network can be utilized in various cases, 280 as detailed in the following sections. 282 3.1. Traffic Planning, Monitoring and Automatic Network Adjustments 284 Currently there is a schism between network planning for packet and 285 optical transport networks. Sometimes these networks are 286 administered, operated and planned independently even when they are a 287 part of a single trusted domain. Any change in traffic requirements 288 requires long business process to make changes in the network. In 289 dynamic networks this is no longer acceptable. 291 A unified Packet+Optical traffic planning tool can be developed which 292 uses the traffic demand matrix to plan the optical transport network. 294 Further based on traffic demand changes, historical data, traffic 295 prediction and monitoring, changes should be made to the optical 296 transport network. An access to abstract topology of the optical 297 transport network based on established and potential (on-demand) 298 tunnels in optical transport network can provide mechanism to handle 299 this. 301 Further optical bypass may be established automatically to offload 302 the continuous changing traffic to optical transport network allowing 303 streamlined business process between packet and optical transport 304 networks. 306 3.1.1. Automated Congestion Management 308 Congestion management and synergized network optimization for packet 309 and optical transport networks can eliminate the need for overbooking 310 of optical transport networks as dumb pipes. Application could be 311 written that provide automated congestion management and network 312 optimization. Automated congestion management recognizes prolonged 313 congestion in the network and works with the controllers to add 314 bandwidth at an optical transport layer, to alleviate the congestion, 315 or make changes in the packet layer to reroute traffic around the 316 congestion. 318 For such applications there is a clear need for an abstract network 319 topology of optical transport layer, further there is also a need for 320 a synergy of cost and SLA across optical and packet networks. 322 3.2. Protection and Restoration Synergy 324 The protection and restoration are usually handled individually in 325 Packet and optical layer. There is a need for synergy and optimized 326 handling of protection of resources across layers. A lot more 327 resources in the optical transport network are booked for backup then 328 actually required since there is a lack of coordination between 329 packet and optical layers. The access to abstract graph of optical 330 transport network with information pertaining to backup path 331 information can help the packet network to handle protection, shared 332 risk, fault restoration in an optimized way. Informing the packet 333 network about both working and protection path which are either 334 already established, or potential path can be useful. 336 A significant improvements in overall network availability that can 337 be achieved by using optical transport shared-risk link group (SRLG) 338 information to guide packet network decisions; for example, to avoid 339 or minimize common SRLGs for the main (working) path and the loop 340 free alternative or traffic engineered fast reroute (LFA/TE FRR) 341 back-up path. Shared risk information need to be synergized between 342 the packet and optical. A mechanism to provide abstracted SRLG 343 information can help the packet network consider this information 344 while handling protection and restoration. 346 3.3. Service Awareness 348 In certain networks like financial information network (stock/ 349 commodity trading) and enterprises using cloud based applications, 350 Latency (delay), Latency-Variation (jitter), Packet Loss and 351 Bandwidth Utilization are associated with the SLA. These SLAs must 352 be synergized across packet and optical transport networks. Network 353 optimization evaluates network resource usage at all layers and 354 recommends or executes service path changes while ensuring SLA 355 compliance. It thus makes more effective use of the network, and 356 relieves current or potential congestion. 358 The main economic benefits of ACTN arise from its ability to maintain 359 the SLA of the services at reduced overall network cost considering 360 both packet and optical transport network. Operational benefits of 361 the ACTN also stem from greater flexibility in handling dynamic 362 traffic such as demand uncertainty or variations over time, or 363 optimization based on cost or latency, or improved handling of 364 catastrophic failures. 366 3.4. Coordination between Multiple Network Domains 368 In some deployments, optical transport network may further be divided 369 into multiple domains, an abstracted topology comprising of multiple 370 optical domains MAY be provided to the packet network. A Seamless 371 aggregation and orchestration across multiple optical transport 372 domains is achieved via the VNC, a great help in such deployments. 374 Another interesting deployment involves multiple packet network 375 domains. There exist scenarios where the topology provided to the 376 packet network domains may be different based on the initial demand 377 matrix as well as, management, security and policy considerations. 379 The ACTN framework as described in [ACTN-FWK] should support the 380 aggregation and orchestration across network domains and layers. 382 Further Figure 3 shows a multi-domain scenario where multiple PNC 383 (each controlling a packet or optical domain) and a VNC coordinating 384 among them and providing a consolidated view. 386 +-------------------------+ 387 | VNC | 388 | | 389 +-------------------------+ 390 * 391 +------------+---------+--+ * +-----------+---------+--+ 392 | +---------+ | * | +---------+ | 393 | | PNC ************************* PNC | | 394 | +---------+---------+ | * | +---------+---------+ | 395 | | | | * | | | | 396 | | | | * | | | | 397 | | | | * | | | | 398 | | Packet | | * | | Packet | | 399 | +-------------------+ | * | +-------------------+ | 400 | | * | | 401 | | * | | 402 | | * | | 403 | | * | | 404 | | * | | 405 | +---------+ | * | +---------+ | 406 | | PNC ************************* PNC | | 407 | +---------+---------+ | | +---------+---------+ | 408 | | | | | | | | 409 | | | | | | | | 410 | | | | | | | | 411 | | Optical | | | | Optical | | 412 | +-------------------+ | | +-------------------+ | 413 +---+-------------------+-+ +--+-------------------+-+ 415 Domain 1 Domain 2 417 Figure 3: Coordination between Multiple Network Domains 419 4. Typical Workflow 421 Consider a two-layer network where the higher-layer network is a 422 packet-based IP/MPLS or GMPLS network and the lower-layer network is 423 a GMPLS-controlled optical network both under a common administrative 424 control. 426 The PNC in both layers are under a common VNC that coordinates 427 between the two layers. And this multi-layer network is used to 428 interconnect DCs, where the DC controller (customer network 429 controller - CNC) takes charge as shown in Figure 4. 431 Data Center 432 ***** Controller 433 -------------------------------------*CNC*------------- 434 | ***** | 435 | | Multi-layer | 436 | v Coordinator | 437 | ***** | 438 | *VNC*-- | 439 Data | ***** | | 440 Center | | | 441 +----+ | ***** | +----+ | 442 | DC1|<- *PNC*<- | DC3|<- 443 +----+ | ***** | +----+ | 444 .....|.. Packet | .... | 445 +----+ | . +-----------------------------------+ | .+----+ | 446 | DC2|<- .. /R R R R..../...|..| DC4|<- 447 +----+ / R R / | +----+ 448 ........./....R . R . R R../.....|..... 449 +-----------------------------------+ | 450 Packet . . . . . . | 451 Layer . . . . . . | 452 . . . . . . ***** | 453 . . . . . . *PNC*<- 454 . . . . . . ***** Optical 455 +-----------------------------------+ 456 / O . O . O . O O / 457 / O . O O / 458 Optical / O O O O O / 459 Layer +-----------------------------------+ 461 Figure 4: Typical Workflow 463 Data centre controller (as Customer Network Controller) interfaces 464 the data centre application stratum, it understands multiple DC 465 application requirements and their service needs. DC Controller 466 provides its traffic demand matrix that describes bandwidth 467 requirements and other optional QoS parameters (e.g., latency, 468 diversity requirement, etc.) for each pair of inter-DC connections. 469 The VNC (multi-layer coordinator) sits between the DC controller (CNC 470 - the one issuing connectivity requests) and the physical network 471 controllers (the one managing the resources). In this case each 472 layer has its own PNC managing the resources in each layer with VNC 473 acting as a multi-layer coordinator. The PNC is in charge of 474 configuring the network elements, monitoring the physical topology of 475 the network and passing it, either raw or abstracted, to the VNC. 477 VNC with the help of PNC(s) coordinates network resource control and 478 utilization facilitating network efficiency and network automation. 479 The VNC are also responsible for the abstract topology and the level 480 of abstraction, which facilitate various DC usecases like VM 481 Migrations, global load balancing among geographically distributed 482 DCs, Business continuity and disaster recovery etc using the ACTN 483 framework in an elastic and dynamic and way, improving overall 484 network operations and scaling. 486 Based on the Data centre controller's (acting as CNC) requests for 487 virtual network paths, the VNC mediates with the PNCs and maps these 488 'virtual' request to inter-layer coordinated path computation and 489 provisioning requests in the 'physical' domain to the PNC. Thus VNC 490 acts as a multi-layer coordinator both in respect to multi-layer end 491 to end optimized path computation as well as multi-layer signaling 492 and provisioning. The path computation and abstract topology 493 creation would be based on the guidelines set by the CNC including 494 the optimization criteria, traffic profile, policy etc. 496 In case the PNC could not fulfill the desired request from VNC and 497 indirectly from DC controller, there should be a feedback loop to the 498 VNC so that suitable actions including path recalculation and 499 signaling, negotiation of parameters and attributes with DC 500 controller etc can be undertaken. Thus VNC effectively arbitrate 501 between the customers (DC) and the existing network (PNC) in this 502 example. 504 5. Security Considerations 506 TBD. 508 6. IANA Considerations 510 None, this is an informational document. 512 7. Acknowledgments 514 8. References 516 8.1. Normative References 518 [ACTN-FWK] 519 Ceccarelli, D., Fang, L., Lee, Y., and D. Lopez, 520 "Framework for Abstraction and Control of Transport 521 Networks (draft-ceccarelli-actn-framework)", September 522 2014. 524 8.2. Informative References 526 [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, 527 "Generalized Multiprotocol Label Switching (GMPLS) User- 528 Network Interface (UNI): Resource ReserVation Protocol- 529 Traffic Engineering (RSVP-TE) Support for the Overlay 530 Model", RFC 4208, October 2005. 532 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 533 Element (PCE)-Based Architecture", RFC 4655, August 2006. 535 [RFC5623] Oki, E., Takeda, T., Le Roux, JL., and A. Farrel, 536 "Framework for PCE-Based Inter-Layer MPLS and GMPLS 537 Traffic Engineering", RFC 5623, September 2009. 539 [STATEFUL-PCE] 540 Crabbe, E., Medved, J., Minei, I., and R. Varga, "PCEP 541 Extensions for Stateful PCE [draft-ietf-pce-stateful- 542 pce]", June 2014. 544 [STATEFUL-PCE-INITIATED] 545 Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 546 Extensions for PCE-initiated LSP Setup in a Stateful PCE 547 Model [draft-ietf-pce-pce-initiated-lsp]", June 2014. 549 [ACTN-PROBLEM] 550 Lee, Y., King, D., Boucadair, M., Jing, R., and L. 551 Contreras Murillo, "Problem Statement for Abstraction and 552 Control of Transport Networks (draft-leeking-actn-problem- 553 statement)", September 2014. 555 Appendix A. Contributor Addresses 557 Udayasree Palle 558 Huawei Technologies 559 Leela Palace 560 Bangalore, Karnataka 560008 561 INDIA 563 EMail: udayasree.palle@huawei.com 565 Authors' Addresses 567 Dhruv Dhody 568 Huawei Technologies 569 Leela Palace 570 Bangalore, Karnataka 560008 571 INDIA 573 EMail: dhruv.ietf@gmail.com 575 Xian Zhang 576 Huawei Technologies 577 Bantian, Longgang District 578 Shenzhen, Guangdong 518129 579 P.R.China 581 EMail: zhang.xian@huawei.com 583 Oscar Gonzalez de Dios 584 Telefonica 585 SPAIN 587 EMail: ogondio@tid.es 589 Daniele Ceccarelli 590 Ericsson 591 Via E. Melen 77, Genova - Erzelli 592 Italy 594 EMail: daniele.ceccarelli@ericsson.com 595 Bin-Yeong Yoon 596 ETRI 597 South Korea 599 EMail: byyun@etri.re.kr