idnits 2.17.1 draft-dhodyzhang-actn-use-case-00.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 : ---------------------------------------------------------------------------- No issues found here. 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 (February 14, 2014) is 3724 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 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: August 18, 2014 O. Gonzalez de Dios 6 Telefonica 7 February 14, 2014 9 Use Cases for Abstraction and Control of Transport Networks (ACTN) 10 draft-dhodyzhang-actn-use-case-00 12 Abstract 14 This document describes the Abstraction and Control of Transport 15 Networks (ACTN) use cases that may be potentially deployed in various 16 transport networks and apply to different applications. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on August 18, 2014. 35 Copyright Notice 37 Copyright (c) 2014 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Data Center Interconnect . . . . . . . . . . . . . . . . . . 3 56 3.1. Cross Stratum Optimization . . . . . . . . . . . . . . . 5 57 4. Packet Optical Integration . . . . . . . . . . . . . . . . . 6 58 5. Service Provider . . . . . . . . . . . . . . . . . . . . . . 6 59 5.1. Carriers-of-Carrier . . . . . . . . . . . . . . . . . . . 7 60 5.2. Virtual Network Provider . . . . . . . . . . . . . . . . 8 61 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 62 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 63 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 64 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 65 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 66 9.2. Informative References . . . . . . . . . . . . . . . . . 9 67 Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 10 69 1. Introduction 71 The transport networks are in an unique position to embrace the 72 concepts of software defined networking (SDN) because of the existing 73 separation in control and forwarding plane via GMPLS/ASON. The path 74 computation element (PCE) [RFC4655] and its stateful extension 75 [STATEFUL-PCE] can further provide a central control over the 76 resources. Abstraction and Control of Transport Network (ACTN) is 77 focused on building over the existing blocks by adding 78 programmability, access and control over abstract virtual topologies. 79 [ACTN-PROBLEM] and [ACTN-FWK] provides detailed information regarding 80 this work. 82 This document explores the use cases of ACTN to help provide 83 programmable network services like access to abstract topology and 84 control over the resources. They are divided into - 86 o Data Center Interconnect (DCI): helps organization meet business 87 continuity and improve productivity, transparently connect the 88 geographically dispersed datacenters interconnected via transport 89 network enabling data replication, server clustering, and workload 90 mobility etc. 92 o Packet Optical Integration (POI): Increasingly there is a need for 93 packet and optical transport networks to work together to provide 94 accelerated services. Transport networks can provide useful 95 information to the packet network allowing it to make intelligent 96 decisions and control its allocated resources. It is preferable 97 to coordinate network resource control and utilization rather than 98 controlling and optimizing resources at each network layer (packet 99 and optical transport network) independently. This facilitates 100 network efficiency and network automation. 102 o Service Provider: Service providers are the providers of virtual 103 network services to their customers. Service providers may or may 104 not own physical network resources. 106 o 108 * Carriers-of-Carrier: A two-tiered relationship between a 109 provider carrier and a customer carrier where the provider 110 carrier may offer abstract information and partial control. 112 * Virtual Network Operator: Virtual Network Operator are 113 categorized as virtual because they provide network services to 114 customers without owning the underlying network. 116 1.1. Requirements Language 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in [RFC2119]. 122 2. Terminology 124 Refer [ACTN-FWK] for PNC, VNC terminology. 126 The following terminology is used in this document. 128 ACTN: Abstraction and Control of Transport Networks. 130 DCI: Data Center Interconnect. 132 PCE: Path Computation Element. An entity (component, application, 133 or network node) that is capable of computing a network path or 134 route based on a network graph and applying computational 135 constraints. 137 POI: Packet and Optical Integration 139 VNO: Virtual Network Operator. 141 3. Data Center Interconnect 143 Data center based applications can provide a wide variety of services 144 such as video gaming, cloud computing, and grid applications. High- 145 bandwidth video applications are also emerging, such as remote 146 medical surgery, live concerts, and sporting events. 148 The rapid growth of Internet and cloud computing applications has 149 resulted in an ever increasing datacenter network bandwidth 150 requirements. Datacenter operators are faced with the challenge of 151 meeting exponentially increasing demands for network bandwidth 152 without exorbitant increases in infrastructure cost. The expansion 153 of cloud computing, content delivery, and application agility are 154 driving the need for data center interconnection (DCI). 156 In order to support new and emerging cloud-based applications, such 157 as real-time data backup, virtual machine migration, server 158 clustering or load reorganization, the dynamic provisioning and 159 allocation of IT resources and the interconnection of multiple, 160 remote Data Centers (DC) is a growing requirement. These operations 161 require traffic being delivered between data centers, and, typically, 162 the connections providing such inter-DC connectivity are provisioned 163 using static circuits or dedicated leased lines, leading to an 164 inefficiency in terms of resource utilization. Moreover, a basic 165 requirement is that such a group of remote DCs an be operated 166 logically as one. 168 A flexible data center interconnects is based on simplifying the 169 architecture and using elegant programmable and orchestration 170 capabilities. At the same time, it should enables the dynamic 171 control of services and service attributes such as allocation of 172 bandwidth on demand or tuning of class of service all in a multi- 173 vendor environment. 175 The increase in traffic volumes for the transport network and 176 volatility also results in significantly increased operational 177 complexity, which impacts a service provider's ability to deliver 178 profitable services and create competitive differentiation. A much 179 more agile, scalable and resilient framework is required to meet the 180 dynamic traffic demands of cloud computing. Transport networks lack 181 the end-to-end flexibility and efficiency required to meet the needs 182 of new and demanding needs of data center interconnect. To help 183 operators address the end-to-end service requirements an agile data 184 center connectivity is required with the understanding of the data 185 center applications. 187 Thus a need to provide network abstraction has emerged as a key 188 requirement for Data Center (DC) operators; this implies in effect 189 the virtualization of network interconnecting the DCs, so that the 190 network is "sliced" and DC operator given a partial view of the 191 topology. The Data Center Controller (customer controller) is 192 empowered with various control facilitates (to create, modify, and 193 delete their slice of virtual network services), allowing DC to 194 introduction new services and respond to the changing traffic and SLA 195 demands. 197 Incase of multiple independent network providers interconnecting 198 geographically dispersed Data Centers, a service provider that 199 abstracts the transport network across domains on behalf of the Data 200 Center Controller. 202 +----------------------+ 203 | Data Center | 204 | Controller | 205 +----------------------+ 206 | 207 +----------------------+ 208 | VNC | 209 | | 210 +----------------------+ 211 / \ 212 +--------------+ +--------------+ 213 | PNC1 | | PNC2 | 214 +----------+ |--------------| |--------------| +----------+ 215 | | | | | | | | 216 | DC1 | | Network | | Network | | DC2 | 217 | | | provider 1 | | provider 2 | | | 218 +----------+ | | | | +----------+ 219 +--------------+ +--------------+ 221 Figure 1: Geographically Dispersed DC 223 3.1. Cross Stratum Optimization 225 Currently application decisions are made with very little or no 226 information concerning the underlying network used to deliver those 227 services. Hence such decisions may be sub-optimal from both 228 application and network resource utilization and quality of service 229 objectives. 231 The decisions by the DC or customer controller are typically made by 232 them with very little or no information concerning the underlying 233 network. Hence, such decisions may be sub-optimal from application 234 and network resource utilization and quality of service objectives. 235 ross-stratum optimization is the process of optimizing both the 236 application experience and the network utilization by coordinating 237 decisions in the application stratum and the network stratum. An 238 abstract topological view of the network can go a long way in cross 239 optimization of application and network resources. Further flexible 240 dynamic control over the transport network resources leads to 241 adaptability to handle various traffic loads, data center and network 242 events. 244 4. Packet Optical Integration 246 Connections (or tunnels) formed across the optical transport network, 247 can be used as virtual TE links in the packet network. The 248 relationship is reduced to determining which tunnels to set up, how 249 to trigger them, how to route them, and what capacity to assign them. 250 As the demands in the packet network vary, these tunnels may need to 251 be modified. 253 An entity in packet network - (maybe a Path Computation Element 254 (PCE), Virtual Network Topology Manager (VNTM) [RFC5623], Controller 255 etc..) should be aware of the abstract topology of the transport 256 network. This entity is the customer controller as per [ACTN-FWK] 257 which interacts with Virtual Network Controller (VNC). The abstract 258 topology may consist of established tunnels in optical transport 259 network or ones that can be created on demand. The level of 260 abstraction is dependent on various management, security and policy 261 considerations. This abstract topology information in the packet 262 network can be utilized in various cases - 264 o Traffic Planning, Monitoring and Automatic Network Adjustments 266 o Automated Unified Congestion Management 268 o Protection and Restoration Synergy across Packet and Optical 270 o Service Awareness across Packet and Optical 272 They are described in detail in [ACTN-POI-USECASE] 274 5. Service Provider 276 Service providers as an entity is described in [ACTN-FWK] - as a 277 provider of virtual network services to their customers. Service 278 providers may or may not own physical network resources. When a 279 service provider is the same as the network provider, this is similar 280 to traditional VPN models. This model works well when the customer 281 maintains a single interface with a single provider. When customer 282 location spans across multiple independent network provider domains, 283 then it becomes hard to facilitate the creation of end-to-end virtual 284 network services with this model. A more interesting case arises 285 when network providers only provide infrastructure while service 286 providers directly interface their customers. In this case, service 287 providers themselves are customers of the network infrastructure 288 providers. One service provider may need to keep multiple 289 independent network providers as its end-users span geographically 290 across multiple network provider domains (Figure 1). 292 5.1. Carriers-of-Carrier 294 The customer of a VPN service provider might be a service provider 295 for the end customer. [RFC4364] describes two main types of carrier- 296 of-carriers VPNs: 298 o Internet Service Provider as the Customer - The VPN customer is an 299 ISP that uses the VPN service provider network to connect its 300 geographically disparate regional networks. 302 o VPN Service Provider as the Customer - The VPN customer is itself 303 a VPN service provider offering VPN service to its customers. The 304 carrier-of-carriers VPN service customer relies on the backbone 305 VPN service provider for inter-site connectivity. 307 [ACTN-FWK] supports such recursiveness - a customers of a given 308 service provider can in turn offer a service to other customers and 309 thus well suited for such use-case. 311 +-----+ 312 | VPN | 313 | A | 314 +-----+ 315 | 316 +----------------------+ +-----+ 317 | VPN Customer |-| VPN | 318 | | | B | 319 +----------------------+ +-----+ 320 | 321 +----------------------+ 322 | Backbone VPN | 323 | Provider | 324 +----------------------+ 325 | 326 +-----+ +----------------------+ 327 | VPN |-| VPN Customer | 328 | A | | | 329 +-----+ +----------------------+ 330 | 331 +-----+ 332 | VPN | 333 | B | 334 +-----+ 336 Figure 2: Carriers-of-Carrier 338 5.2. Virtual Network Provider 340 A virtual network provides a communications services without owning 341 the network infrastructure over which it provides services to its 342 customers. An virtual network operator enters into a business 343 agreement with a physical network operator to obtain bulk access to 344 network services at wholesale rates, then sets retail prices 345 independently. An virtual network operator may use its own customer 346 service, billing, marketing and sales in some cases. 348 ACTN framework ([ACTN-FWK]) provides tools for the Virtual Network 349 Operator (VNO) to control the leased physical network slice in a much 350 granular level by less abstraction and thus providing more control. 352 6. Security Considerations 354 TBD. 356 7. IANA Considerations 358 None, this is an informational document. 360 8. Acknowledgments 362 TBD. 364 9. References 366 9.1. Normative References 368 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 369 Requirement Levels", BCP 14, RFC 2119, March 1997. 371 9.2. Informative References 373 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 374 Networks (VPNs)", RFC 4364, February 2006. 376 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 377 Element (PCE)-Based Architecture", RFC 4655, August 2006. 379 [RFC5623] Oki, E., Takeda, T., Le Roux, JL., and A. Farrel, 380 "Framework for PCE-Based Inter-Layer MPLS and GMPLS 381 Traffic Engineering", RFC 5623, September 2009. 383 [STATEFUL-PCE] 384 Crabbe, E., Medved, J., Minei, I., and R. Varga, "PCEP 385 Extensions for Stateful PCE [draft-ietf-pce-stateful- 386 pce]", October 2013. 388 [ACTN-FWK] 389 Ceccarelli, D., Fang, L., Lee, Y., and D. Lopez, 390 "Framework for Abstraction and Control of Transport 391 Networks (draft-ceccarelli-actn-framework)", February 392 2014. 394 [ACTN-PROBLEM] 395 Lee, Y. and D. King, "Problem Statement for Abstraction 396 and Control of Transport Networks (draft-leeking-actn- 397 problem-statement)", February 2014. 399 [ACTN-POI-USECASE] 400 Dhody, D., Zhang, X., Gonzalez de Dios, O., and D. 401 Ceccarelli, "Packet Optical Integration (POI) Use Cases 402 for Abstraction and Control of Transport Networks (ACTN) 403 (draft-dhody-actn-poi-use-case)", February 2014. 405 Appendix A. Contributor Addresses 407 Luyuan Fang 408 Microsoft 409 USA 410 EMail: luyuanf@gmail.com 412 Ning So 413 Tata Communications 414 USA 415 EMail: Ning.So@tatacommunications.com 417 Young Lee 418 Huawei Technologies 419 5340 Legacy Drive 420 Plano, TX 75023, USA 421 Email: leeyoung@huawei.com 423 Daniel King 424 Old Dog Consulting 425 UK 426 EMail: daniel@olddog.co.uk 428 Daniel Ceccarelli 429 Ericsson 430 Via Melen, 77 431 Genova, Italy 432 Email: daniele.ceccarelli@ericsson.com 434 Authors' Addresses 436 Dhruv Dhody 437 Huawei Technologies 438 Leela Palace 439 Bangalore, Karnataka 560008 440 INDIA 442 EMail: dhruv.ietf@gmail.com 444 Xian Zhang 445 Huawei Technologies 446 Bantian, Longgang District 447 Shenzhen, Guangdong 518129 448 P.R.China 450 EMail: zhang.xian@huawei.com 451 Oscar Gonzalez de Dios 452 Telefonica 453 SPAIN 455 EMail: ogondio@tid.es