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]