[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/