One document matched: draft-dhody-actn-poi-use-case-00.txt

ACTN BOF                                                        D. Dhody
Internet-Draft                                                  X. Zhang
Intended status: Informational                       Huawei Technologies
Expires: July 14, 2014                               O. Gonzalez de Dios
                                                              Telefonica
                                                        January 10, 2014


 Packet Optical Integration (POI) Use Cases for Abstraction and Control
                      of Transport Networks (ACTN)
                    draft-dhody-actn-poi-use-case-00

Abstract

   This document describes the Abstraction and Control of Transport
   Networks (ACTN) use cases related to Packet and Optical Integration
   (POI), 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 July 14, 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



Dhody, et al.             Expires July 14, 2014                 [Page 1]

Internet-Draft              ACTN-POI-USECASE                January 2014


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Packet Optical Integration  . . . . . . . . . . . . . . . . .   3
     3.1.  Traffic Planning, Monitoring and Automatic Network
           Adjustments . . . . . . . . . . . . . . . . . . . . . . .   4
       3.1.1.  Automated Congestion Management . . . . . . . . . . .   4
     3.2.  Protection and Restoration Synergy  . . . . . . . . . . .   4
     3.3.  Service Awareness . . . . . . . . . . . . . . . . . . . .   5
     3.4.  Coordination between Multiple Network Domains . . . . . .   5
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   6.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   6
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Appendix A.  Contributor Addresses  . . . . . . . . . . . . . . .   7

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-FWK] provides detailed information regarding this work.

   It is preferable to coordinate network resource control and
   utilization rather than controlling and optimizing resources at each
   network layer (packet and optical transport network) independently.
   This facilitates network efficiency and network automation.

   This document explores the Packet and Optical Integration (POI) use
   cases of ACTN to help provide programmable network services like
   access to abstract topology and control over the resources.
   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.  In this POI use-case, we regard packet networks as a



Dhody, et al.             Expires July 14, 2014                 [Page 2]

Internet-Draft              ACTN-POI-USECASE                January 2014


   consumer to transport networks.  It is interesting to note that the
   Packet networks themselves may have their ultimate clients to
   support.  The use case described in this document are primarily
   concerned with 'packet network as a consumer' in a single trusted
   domain.

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

   The following terminology is used in this document.

   ACTN:  Abstraction and Control of Transport Networks.

   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

   VNTM:  Virtual Network Topology Manager

3.  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.
   The topology may consist of established tunnels in 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, as detailed in the following sections.







Dhody, et al.             Expires July 14, 2014                 [Page 3]

Internet-Draft              ACTN-POI-USECASE                January 2014


3.1.  Traffic Planning, Monitoring and Automatic Network Adjustments

   Currently there is a schism between network planning for packet and
   optical transport networks.  Sometimes these networks are
   administered, operated and planned independently even when they are a
   part of a single trusted domain.  Any change in traffic requirements
   requires long business process to make changes in the network.  In
   dynamic networks this is no longer acceptable.

   A unified Packet+Optical traffic planning tool can be developed which
   uses the traffic demand matrix to plan the optical transport network.
   Further based on traffic demand changes, historical data, traffic
   prediction and monitoring, changes should be made to the optical
   transport network.  An access to abstract topology of the optical
   transport network based on established and potential (on-demand)
   tunnels in transport network can provide mechanism to handle this.

   Further optical bypass may be established automatically to offload
   the continuous changing traffic to transport network allowing
   streamlined business process between packet and optical transport
   networks.

3.1.1.  Automated Congestion Management

   Congestion management and synergized network optimization for packet
   and transport networks can eliminate the need for overbooking of
   transport networks as dumb pipes.  Application could be written that
   provide automated congestion management and network optimization.
   Automated congestion management recognizes prolonged congestion in
   the network and works with the controllers to add bandwidth at a
   transport layer, to alleviate the congestion, or make changes in the
   packet layer to reroute traffic around the congestion.

   For such applications there is a clear need for an abstract network
   topology of optical transport layer, further there is also a need for
   a synergy of cost and SLA across optical and packet networks.

3.2.  Protection and Restoration Synergy

   The protection and restoration are usually handled individually in
   Packet and optical layer.  There is a need for synergy and optimized
   handling of protection of resources across layers.  A lot more
   resources in the optical transport network are booked for backup then
   actually required since there is a lack of coordination between
   packet and optical layers.  The access to abstract graph of transport
   network with information pertaining to backup path information can
   help the packet network to handle protection, shared risk, fault
   restoration in an optimized way.  Informing the packet network about



Dhody, et al.             Expires July 14, 2014                 [Page 4]

Internet-Draft              ACTN-POI-USECASE                January 2014


   both working and protection path which are either already
   established, or potential path can be useful.

   A significant improvements in overall network availability that can
   be achieved by using optical transport shared-risk link group (SRLG)
   information to guide packet network decisions; for example, to avoid
   or minimize common SRLGs for the main (working) path and the loop
   free alternative or traffic engineered fast reroute (LFA/TE FRR)
   back-up path.  Shared risk information need to be synergized between
   the packet and optical.  A mechanism to provide abstracted SRLG
   information can help the packet network consider this information
   while handling protection and restoration.

3.3.  Service Awareness

   In certain networks like financial information network (stock/
   commodity trading) and enterprises using cloud based applications,
   Latency (delay), Latency-Variation (jitter), Packet Loss and
   Bandwidth Utilization are associated with the SLA.  These SLAs must
   be synergized across packet and optical transport networks.  Network
   optimization evaluates network resource usage at all layers and
   recommends or executes service path changes while ensuring SLA
   compliance.  It thus makes more effective use of the network, and
   relieves current or potential congestion.

   The main economic benefits of ACTN arise from its ability to maintain
   the SLA of the services at reduced overall network cost considering
   both packet and optical transport network.  Operational benefits of
   the ACTN also stem from greater flexibility in handling dynamic
   traffic such as demand uncertainty or variations over time, or
   optimization based on cost or latency, or improved handling of
   catastrophic failures.

3.4.  Coordination between Multiple Network Domains

   In some deployments, optical transport network may further be divided
   into multiple domains, an abstracted topology comprising of multiple
   optical domains MAY be provided to the packet network.  A Seamless
   aggregation and orchestration across multiple optical transport
   domains will be a great help in such deployments.

   Another interesting deployment involves multiple packet network
   domains.  There exist scenarios where the topology provided to the
   packet network domains may be different based on the initial demand
   matrix as well as, management, security and policy considerations.

   The ACTN framework as described in [ACTN-FWK] should support the
   aggregation and orchestration across network domains and layers.



Dhody, et al.             Expires July 14, 2014                 [Page 5]

Internet-Draft              ACTN-POI-USECASE                January 2014


4.  Security Considerations

   TBD.

5.  IANA Considerations

   None, this is an informational document.

6.  Acknowledgments

   TBD.

7.  References

7.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

7.2.  Informative References

   [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)", January 2014.














Dhody, et al.             Expires July 14, 2014                 [Page 6]

Internet-Draft              ACTN-POI-USECASE                January 2014


Appendix A.  Contributor Addresses

   Udayasree Palle
   Huawei Technologies
   Leela Palace
   Bangalore, Karnataka  560008
   INDIA

   EMail: udayasree.palle@huawei.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


   Oscar Gonzalez de Dios
   Telefonica
   SPAIN

   EMail: ogondio@tid.es
















Dhody, et al.             Expires July 14, 2014                 [Page 7]