ACTN BOF D. Dhody Internet-Draft X. Zhang Intended status: Informational Huawei Technologies Expires: August 18, 2014 O. Gonzalez de Dios Telefonica February 14, 2014 Use Cases for Abstraction and Control of Transport Networks (ACTN) draft-dhodyzhang-actn-use-case-00 Abstract This document describes the Abstraction and Control of Transport Networks (ACTN) use cases that may be potentially deployed in various transport networks and apply to different applications. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on August 18, 2014. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Dhody, et al. Expires August 18, 2014 [Page 1] Internet-Draft ACTN-USECASE February 2014 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Data Center Interconnect . . . . . . . . . . . . . . . . . . 3 3.1. Cross Stratum Optimization . . . . . . . . . . . . . . . 5 4. Packet Optical Integration . . . . . . . . . . . . . . . . . 6 5. Service Provider . . . . . . . . . . . . . . . . . . . . . . 6 5.1. Carriers-of-Carrier . . . . . . . . . . . . . . . . . . . 7 5.2. Virtual Network Provider . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 9.2. Informative References . . . . . . . . . . . . . . . . . 9 Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 10 1. Introduction The transport networks are in an unique position to embrace the concepts of software defined networking (SDN) because of the existing separation in control and forwarding plane via GMPLS/ASON. The path computation element (PCE) [RFC4655] and its stateful extension [STATEFUL-PCE] can further provide a central control over the resources. Abstraction and Control of Transport Network (ACTN) is focused on building over the existing blocks by adding programmability, access and control over abstract virtual topologies. [ACTN-PROBLEM] and [ACTN-FWK] provides detailed information regarding this work. This document explores the use cases of ACTN to help provide programmable network services like access to abstract topology and control over the resources. They are divided into - o Data Center Interconnect (DCI): helps organization meet business continuity and improve productivity, transparently connect the geographically dispersed datacenters interconnected via transport network enabling data replication, server clustering, and workload mobility etc. o Packet Optical Integration (POI): Increasingly there is a need for packet and optical transport networks to work together to provide accelerated services. Transport networks can provide useful information to the packet network allowing it to make intelligent decisions and control its allocated resources. It is preferable to coordinate network resource control and utilization rather than Dhody, et al. Expires August 18, 2014 [Page 2] Internet-Draft ACTN-USECASE February 2014 controlling and optimizing resources at each network layer (packet and optical transport network) independently. This facilitates network efficiency and network automation. o Service Provider: Service providers are the providers of virtual network services to their customers. Service providers may or may not own physical network resources. o * Carriers-of-Carrier: A two-tiered relationship between a provider carrier and a customer carrier where the provider carrier may offer abstract information and partial control. * Virtual Network Operator: Virtual Network Operator are categorized as virtual because they provide network services to customers without owning the underlying network. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Terminology Refer [ACTN-FWK] for PNC, VNC terminology. The following terminology is used in this document. ACTN: Abstraction and Control of Transport Networks. DCI: Data Center Interconnect. PCE: Path Computation Element. An entity (component, application, or network node) that is capable of computing a network path or route based on a network graph and applying computational constraints. POI: Packet and Optical Integration VNO: Virtual Network Operator. 3. Data Center Interconnect Data center based applications can provide a wide variety of services such as video gaming, cloud computing, and grid applications. High- Dhody, et al. Expires August 18, 2014 [Page 3] Internet-Draft ACTN-USECASE February 2014 bandwidth video applications are also emerging, such as remote medical surgery, live concerts, and sporting events. The rapid growth of Internet and cloud computing applications has resulted in an ever increasing datacenter network bandwidth requirements. Datacenter operators are faced with the challenge of meeting exponentially increasing demands for network bandwidth without exorbitant increases in infrastructure cost. The expansion of cloud computing, content delivery, and application agility are driving the need for data center interconnection (DCI). In order to support new and emerging cloud-based applications, such as real-time data backup, virtual machine migration, server clustering or load reorganization, the dynamic provisioning and allocation of IT resources and the interconnection of multiple, remote Data Centers (DC) is a growing requirement. These operations require traffic being delivered between data centers, and, typically, the connections providing such inter-DC connectivity are provisioned using static circuits or dedicated leased lines, leading to an inefficiency in terms of resource utilization. Moreover, a basic requirement is that such a group of remote DCs an be operated logically as one. A flexible data center interconnects is based on simplifying the architecture and using elegant programmable and orchestration capabilities. At the same time, it should enables the dynamic control of services and service attributes such as allocation of bandwidth on demand or tuning of class of service all in a multi- vendor environment. The increase in traffic volumes for the transport network and volatility also results in significantly increased operational complexity, which impacts a service provider's ability to deliver profitable services and create competitive differentiation. A much more agile, scalable and resilient framework is required to meet the dynamic traffic demands of cloud computing. Transport networks lack the end-to-end flexibility and efficiency required to meet the needs of new and demanding needs of data center interconnect. To help operators address the end-to-end service requirements an agile data center connectivity is required with the understanding of the data center applications. Thus a need to provide network abstraction has emerged as a key requirement for Data Center (DC) operators; this implies in effect the virtualization of network interconnecting the DCs, so that the network is "sliced" and DC operator given a partial view of the topology. The Data Center Controller (customer controller) is empowered with various control facilitates (to create, modify, and Dhody, et al. Expires August 18, 2014 [Page 4] Internet-Draft ACTN-USECASE February 2014 delete their slice of virtual network services), allowing DC to introduction new services and respond to the changing traffic and SLA demands. Incase of multiple independent network providers interconnecting geographically dispersed Data Centers, a service provider that abstracts the transport network across domains on behalf of the Data Center Controller. +----------------------+ | Data Center | | Controller | +----------------------+ | +----------------------+ | VNC | | | +----------------------+ / \ +--------------+ +--------------+ | PNC1 | | PNC2 | +----------+ |--------------| |--------------| +----------+ | | | | | | | | | DC1 | | Network | | Network | | DC2 | | | | provider 1 | | provider 2 | | | +----------+ | | | | +----------+ +--------------+ +--------------+ Figure 1: Geographically Dispersed DC 3.1. Cross Stratum Optimization Currently application decisions are made with very little or no information concerning the underlying network used to deliver those services. Hence such decisions may be sub-optimal from both application and network resource utilization and quality of service objectives. The decisions by the DC or customer controller are typically made by them with very little or no information concerning the underlying network. Hence, such decisions may be sub-optimal from application and network resource utilization and quality of service objectives. ross-stratum optimization is the process of optimizing both the application experience and the network utilization by coordinating decisions in the application stratum and the network stratum. An abstract topological view of the network can go a long way in cross optimization of application and network resources. Further flexible Dhody, et al. Expires August 18, 2014 [Page 5] Internet-Draft ACTN-USECASE February 2014 dynamic control over the transport network resources leads to adaptability to handle various traffic loads, data center and network events. 4. Packet Optical Integration Connections (or tunnels) formed across the optical transport network, can be used as virtual TE links in the packet network. The relationship is reduced to determining which tunnels to set up, how to trigger them, how to route them, and what capacity to assign them. As the demands in the packet network vary, these tunnels may need to be modified. An entity in packet network - (maybe a Path Computation Element (PCE), Virtual Network Topology Manager (VNTM) [RFC5623], Controller etc..) should be aware of the abstract topology of the transport network. This entity is the customer controller as per [ACTN-FWK] which interacts with Virtual Network Controller (VNC). The abstract topology may consist of established tunnels in optical transport network or ones that can be created on demand. The level of abstraction is dependent on various management, security and policy considerations. This abstract topology information in the packet network can be utilized in various cases - o Traffic Planning, Monitoring and Automatic Network Adjustments o Automated Unified Congestion Management o Protection and Restoration Synergy across Packet and Optical o Service Awareness across Packet and Optical They are described in detail in [ACTN-POI-USECASE] 5. Service Provider Service providers as an entity is described in [ACTN-FWK] - as a provider of virtual network services to their customers. Service providers may or may not own physical network resources. When a service provider is the same as the network provider, this is similar to traditional VPN models. This model works well when the customer maintains a single interface with a single provider. When customer location spans across multiple independent network provider domains, then it becomes hard to facilitate the creation of end-to-end virtual network services with this model. A more interesting case arises when network providers only provide infrastructure while service providers directly interface their customers. In this case, service providers themselves are customers of the network infrastructure Dhody, et al. Expires August 18, 2014 [Page 6] Internet-Draft ACTN-USECASE February 2014 providers. One service provider may need to keep multiple independent network providers as its end-users span geographically across multiple network provider domains (Figure 1). 5.1. Carriers-of-Carrier The customer of a VPN service provider might be a service provider for the end customer. [RFC4364] describes two main types of carrier- of-carriers VPNs: o Internet Service Provider as the Customer - The VPN customer is an ISP that uses the VPN service provider network to connect its geographically disparate regional networks. o VPN Service Provider as the Customer - The VPN customer is itself a VPN service provider offering VPN service to its customers. The carrier-of-carriers VPN service customer relies on the backbone VPN service provider for inter-site connectivity. [ACTN-FWK] supports such recursiveness - a customers of a given service provider can in turn offer a service to other customers and thus well suited for such use-case. Dhody, et al. Expires August 18, 2014 [Page 7] Internet-Draft ACTN-USECASE February 2014 +-----+ | VPN | | A | +-----+ | +----------------------+ +-----+ | VPN Customer |-| VPN | | | | B | +----------------------+ +-----+ | +----------------------+ | Backbone VPN | | Provider | +----------------------+ | +-----+ +----------------------+ | VPN |-| VPN Customer | | A | | | +-----+ +----------------------+ | +-----+ | VPN | | B | +-----+ Figure 2: Carriers-of-Carrier 5.2. Virtual Network Provider A virtual network provides a communications services without owning the network infrastructure over which it provides services to its customers. An virtual network operator enters into a business agreement with a physical network operator to obtain bulk access to network services at wholesale rates, then sets retail prices independently. An virtual network operator may use its own customer service, billing, marketing and sales in some cases. ACTN framework ([ACTN-FWK]) provides tools for the Virtual Network Operator (VNO) to control the leased physical network slice in a much granular level by less abstraction and thus providing more control. 6. Security Considerations TBD. Dhody, et al. Expires August 18, 2014 [Page 8] Internet-Draft ACTN-USECASE February 2014 7. IANA Considerations None, this is an informational document. 8. Acknowledgments TBD. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 9.2. Informative References [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006. [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006. [RFC5623] Oki, E., Takeda, T., Le Roux, JL., and A. Farrel, "Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering", RFC 5623, September 2009. [STATEFUL-PCE] Crabbe, E., Medved, J., Minei, I., and R. Varga, "PCEP Extensions for Stateful PCE [draft-ietf-pce-stateful- pce]", October 2013. [ACTN-FWK] Ceccarelli, D., Fang, L., Lee, Y., and D. Lopez, "Framework for Abstraction and Control of Transport Networks (draft-ceccarelli-actn-framework)", February 2014. [ACTN-PROBLEM] Lee, Y. and D. King, "Problem Statement for Abstraction and Control of Transport Networks (draft-leeking-actn- problem-statement)", February 2014. [ACTN-POI-USECASE] Dhody, D., Zhang, X., Gonzalez de Dios, O., and D. Ceccarelli, "Packet Optical Integration (POI) Use Cases for Abstraction and Control of Transport Networks (ACTN) (draft-dhody-actn-poi-use-case)", February 2014. Dhody, et al. Expires August 18, 2014 [Page 9] Internet-Draft ACTN-USECASE February 2014 Appendix A. Contributor Addresses Luyuan Fang Microsoft USA EMail: luyuanf@gmail.com Ning So Tata Communications USA EMail: Ning.So@tatacommunications.com Young Lee Huawei Technologies 5340 Legacy Drive Plano, TX 75023, USA Email: leeyoung@huawei.com Daniel King Old Dog Consulting UK EMail: daniel@olddog.co.uk Daniel Ceccarelli Ericsson Via Melen, 77 Genova, Italy Email: daniele.ceccarelli@ericsson.com Authors' Addresses Dhruv Dhody Huawei Technologies Leela Palace Bangalore, Karnataka 560008 INDIA EMail: dhruv.ietf@gmail.com Xian Zhang Huawei Technologies Bantian, Longgang District Shenzhen, Guangdong 518129 P.R.China EMail: zhang.xian@huawei.com Dhody, et al. Expires August 18, 2014 [Page 10] Internet-Draft ACTN-USECASE February 2014 Oscar Gonzalez de Dios Telefonica SPAIN EMail: ogondio@tid.es Dhody, et al. Expires August 18, 2014 [Page 11]