One document matched: draft-dhody-actn-poi-use-case-01.xml

<?xml version="1.0" encoding="us-ascii"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"[]>
<?rfc toc="yes" ?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="4"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="no"?>
<?rfc rfcedstyle="yes"?>
<?rfc subcompact="no"?>
<?rfc compact="yes" ?>
<?rfc iprnotified="Yes" ?>
<?rfc strict="no" ?>
<rfc ipr="trust200902" category="info" docName="draft-dhody-actn-poi-use-case-01" obsoletes="" updates="" submissionType="IETF" xml:lang="en">
  <front>
    <title abbrev="ACTN-POI-USECASE">Packet Optical Integration (POI) 
    Use Cases for Abstraction and Control of Transport Networks (ACTN)</title>
    <author initials="D" surname="Dhody" fullname="Dhruv Dhody">
      <organization>Huawei Technologies</organization>
      <address>
        <postal>
          <street>Leela Palace</street>
          <city>Bangalore</city>
          <region>Karnataka</region>
          <code>560008</code>
          <country>INDIA</country>
        </postal>
        <email>dhruv.ietf@gmail.com</email>
      </address>
    </author>
    <author fullname="Xian Zhang" initials="X." surname="Zhang">
      <organization>Huawei Technologies</organization>
      <address>
	<postal>
	  <street>Bantian, Longgang District
      </street>
	  <city>Shenzhen</city>
	  <region>Guangdong</region>
	  <code>518129</code>
	  <country>P.R.China</country>
	</postal>
	<email>zhang.xian@huawei.com</email>
      </address>
    </author>
    <author initials="O" fullname="Oscar Gonzalez de Dios" surname="Gonzalez de Dios">
      <organization>Telefonica</organization>
      <address>
        <postal>
          <street></street>
          <city></city>
          <region></region>
          <code></code>
          <country>SPAIN</country>
        </postal>
        <email>ogondio@tid.es</email>
      </address>
    </author>
    <author initials="D" fullname="Daniele Ceccarelli" surname="Ceccarelli">
      <organization>Ericsson</organization>
      <address>
        <postal>
          <street></street>
          <city>Via E. Melen 77</city>
          <region>Genova - Erzelli</region>
          <code></code>
          <country>Italy</country>
        </postal>
        <email>daniele.ceccarelli@ericsson.com</email>
      </address>
    </author>
    <date month="February" year="2014" />
    <area>Routing</area>
    <workgroup>ACTN BOF</workgroup>
    <abstract>
      <t>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.</t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction" toc="default">
   <t>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) <xref target="RFC4655"/> and its 
   stateful extension <xref target="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. <xref target="ACTN-PROBLEM"/> and <xref target="ACTN-FWK"/> provides detailed 
   information regarding this work. Further <xref target="ACTN-USECASE"/> describe the overall use-cases for ACTN. 
   This document focuses on the Packet and Optical Integration (POI) use cases of ACTN.</t>
   <t>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.</t>
   <t>In a multi-layer network via client and server networking roles,
    Label Switched Paths (LSPs) in a server (lower) layer are used to 
    carry client (higher) layer LSPs across the server (lower) layer
    network. Basic Packet and Optical Integration (POI) may be achieved by 
    some of the existing mechanism as specified in <xref target="RFC4208"/> and
    <xref target="RFC5623"/>. This document explores the POI use cases
   of ACTN to help provide 
   programmable network services like orchestration, access to abstract topology and 
   control over the resources.</t> 
   <t>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 customer 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 customer' in a single trusted domain.  
    </t>
    
      <section title="Requirements Language" toc="default">
        <t>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 <xref target="RFC2119"/>.</t>
      </section>
    </section>
    <section title="Terminology" toc="default">
      <t>The following terminology is used in this document.</t>
      <t>
        <list style="hanging">
          <t hangText="ACTN:">Abstraction and Control of Transport Networks.</t>
          <t hangText="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.</t>
          <t hangText="POI:">Packet and Optical Integration</t>
          <t hangText="VNTM:">Virtual Network Topology Manager</t>
        </list>
      </t>
    </section>
    <section title="Packet Optical Integration" toc="default">
    <t>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.</t>
   <t>An entity in packet network - (maybe a Path Computation Element (PCE), 
   Virtual Network Topology Manager (VNTM) <xref target="RFC5623"/>, Controller 
   etc..) should be aware of the abstract topology of the transport 
   network. This entity is the customer controller as per 
   <xref target="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, as detailed in the following sections. 
   </t>
    <section title="Traffic Planning, Monitoring and Automatic Network Adjustments" toc="default">
    <t>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. </t>
    <t>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.</t>	
    <t>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.</t>
    <section title="Automated Congestion Management" toc="default">
    <t>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. </t>
    <t>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.</t>
    </section>
    
    </section>
    <section title="Protection and Restoration Synergy" toc="default">
    <t>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 both working and
    protection path which are either already established, or potential path can
    be useful.</t>
    <t>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.  
    </t>
    </section>
    <section title="Service Awareness" toc="default">
    <t>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.</t>
   <t>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.</t>
    </section>
    <section title="Coordination between Multiple Network Domains" toc="default">
    <t>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 is achieved 
    via the VNC, a great help in such deployments.</t> 
    <t>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. </t>
    <t>The ACTN framework as described in <xref target="ACTN-FWK"/> 
    should support the aggregation and orchestration across network domains
    and layers.</t> 
    </section>
    </section>  

    
    
    <section title="Security Considerations" toc="default">
      <t>TBD.</t>
    </section>
    <section title="IANA Considerations" toc="default">
    <t>None, this is an informational document.</t>
    </section>
    <section title="Acknowledgments" toc="default">
      <t>TBD.</t>
    </section>    
  </middle>
  <back>
    <references title="Normative References">
    <?rfc include="reference.RFC.2119.xml" ?>
    </references>
    <references title="Informative References">
    <?rfc include="reference.RFC.4208.xml" ?>
    <?rfc include="reference.RFC.4655.xml" ?>
    <?rfc include="reference.RFC.5623.xml" ?>
    <!--STATEFUL-PCE-->

      <reference anchor="STATEFUL-PCE">
        <front>
          <title>PCEP Extensions for Stateful PCE
          [draft-ietf-pce-stateful-pce]</title>

          <author fullname="Edward Crabbe" initials="E"
                  surname="Crabbe">
            <organization></organization>
          </author>

          <author fullname="Jan Medved" initials="J" surname="Medved">
            <organization></organization>
          </author>

          <author fullname="Ina Minei" initials="I" surname="Minei">
            <organization></organization>
          </author>

          <author fullname="Robert Varga" initials="R" surname="Varga">
            <organization></organization>
          </author>


          <date month="October" year="2013" />
        </front>
      </reference>
    <!--ACTN-FWK-->
      <reference anchor="ACTN-FWK">
        <front>
          <title>Framework for Abstraction and Control of Transport Networks (draft-ceccarelli-actn-framework)</title>
          <author fullname="Daniele Ceccarelli" initials="D" surname="Ceccarelli"></author>
          <author fullname="Luyuan Fang" initials="L" surname="Fang"></author>
          <author fullname="Young Lee" initials="Y" surname="Lee"></author>
          <author fullname="Diego Lopez" initials="D" surname="Lopez"></author>
          <date month="January" year="2014" />
        </front>
      </reference>
      <!--ACTN-PROBLEM-->
      <reference anchor="ACTN-PROBLEM">
        <front>
          <title>Problem Statement for Abstraction and Control of Transport Networks (draft-leeking-actn-problem-statement)</title>
          <author fullname="Young Lee" initials="Y" surname="Lee"></author>
          <author fullname="Daniel King" initials="D" surname="King"></author>
          <date month="February" year="2014" />
        </front>
      </reference>  
      <!--ACTN-USECASE-->
      <reference anchor="ACTN-USECASE">
        <front>
          <title>Use Cases for Abstraction and Control of Transport Networks (ACTN) (draft-dhodyzhang-actn-use-case-00)</title>
          <author fullname="Dhruv Dhody" initials="D" surname="Dhody"></author>
          <author fullname="Xian Zhang" initials="X" surname="Zhang"></author>
          <author fullname="Oscar Gonzalez de Dios" initials="O" surname="Gonzalez de Dios"></author>
          <date month="February" year="2014" />
        </front>
      </reference>            
    </references>
<section title="Contributor Addresses" toc="default">
    <t>
    <figure title="" suppress-title="false" align="left" alt="" width="" height="">
          <artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height=""><![CDATA[
Bin-Yeong Yoon
ETRI
SOUTH KOREA

EMail: byyun@etri.re.kr

Udayasree Palle
Huawei Technologies
Leela Palace
Bangalore, Karnataka  560008
INDIA

EMail: udayasree.palle@huawei.com
        ]]></artwork>
        </figure>
      </t>
    </section>    
  </back>
</rfc>