<?xml version='1.0'?>
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd'>

<?rfc comments='yes'?>
<?rfc docmapping='yes'?>
<?rfc inline='no'?>
<?rfc compact='no'?>
<?rfc editing='no'?>
<?rfc subcompact='no'?>
<?rfc symrefs='yes'?>
<?rfc toc='yes'?>
<?rfc tocappendix='no'?>
<?rfc tocindent='no'?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>

<rfc ipr="trust200902"  category="std" docName="draft-liu-rtgwg-optical2cloud-problem-statement-00">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<front>
 <title abbrev="optical2cloud-ps">Accessing Cloud via Optical Network Problem Statement</title>
   <author fullname="Sheng Liu" initials="S." surname="Liu">
      <organization>China Mobile</organization>
      <address>
    <postal>
      <street></street>
      <city></city>
      <region></region>
      <code></code>
      <country>China</country>
    </postal>
    <email>liushengwl@chinamobile.com</email>
      </address>
    </author>
   <author fullname="Haomian Zheng" initials="H." surname="Zheng ">
      <organization>Huawei Technologies</organization>
      <address>
    <postal>
      <street>H1, Xiliu Beipo Village, Songshan Lake,
      </street>
      <city>Dongguan</city>
      <region>Guangdong</region>
      <code>523808</code>
      <country>China</country>
    </postal>
    <email>zhenghaomian@huawei.com</email>
      </address>
    </author>
    
 <date month='October' day="25" year='2021' />
 <workgroup>RTGWG Working Group</workgroup>
 <abstract>
  <t>This document describes the scenarios and requirements for the Cloud accessing through optical network, as a complementary functionality of the network and cloud coordination. The problem from optical perspective is different with packet, and statement is made in this document. </t>
 </abstract>
</front>

<middle>
<section title="Introduction">
  <t>The cloud-related applications is becoming popular and wider deployed, in enterprises and vertical industries. Companies with multi-campus are interconnected together with the remote cloud, for the purpose of storage and computation. Such cloud services require high-level experiences including high availability, low latency, on-demand adjustment and so on. </t>
  <t>Optical is playing an important role in the transport network, with its own large bandwidth and low latency feature. Based on the TDM switching technology, the data transportation in optical networks does not have any queuing problem to solve and can perfectly avoid congestion. Such features can drastically improve the users experience on the service quality.</t> 
  <t>Optical network is considered as the transportation solution for long-distance. This feature is also suitable for the cloud interconnections, especially when there is demand for large bandwidth.</t> 
  <t> <xref target="I-D.ietf-rtgwg-net2cloud-problem-statement" pageno="false" format="default" /> and <xref target="I-D.ietf-rtgwg-net2cloud-gap-analysis" pageno="false" format="default" />gave a detailed description on the coordination requirements between the network and the cloud, and it is expected the description in this document can be used as a complementary from the optical perspective.</t>
 <section title="Requirements Language">
    <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shown here.</t>
</section>
</section><!-- Introduction -->
<section title="Scenarios">
  <t>With the prevalence of cloud services, enterprises services, home services such as AR/VR, accessing  clouds with optical networks is increasingly attractive and becoming an option for the users. Following scenarios provide a few typical applications.
  </t>
  <section title = "Multi-cloud accessing">
  <t>
  Cloud services are usually supported by multiple interconnected data centers (DCs). Besides the on-demand, scalable, high available and uses-based billing, mentioned in <xref target="I-D.ietf-rtgwg-net2cloud-problem-statement" pageno="false" format="default" />, there are also needs for Data Centre Interconnect (DCI) about high requirements on capacity, latency,  and flexible scheduling. This use case requires specific capabilities of advanced OTN (Optical Transport Network) for DCIs. 
  </t>
  <figure title ="Figure 1: Cloud Accessing through Optical Network">
        <artwork>
  <![CDATA[
    //------\\                                               /----\
  ||Enterprise|\\                                          |Vertical|
  ||   CPE    || \\        ------------          +-----+   /|Cloud |
    \\------//     \ +---*/            \*---+    |Cloud| //  \----/
                     |O-A|              |O-E|----+ GW  |/
                     +---+              +---+    +-----+
                    |      OTN Networks      |
    //-----\\       ++---+              +---+    +-----+     /-----\
  || Vertical||-----+ O-A|              |O-E|----+Cloud|---||Private||
   |   CPE   |      +----*\            /*---+    | GW  |    | Cloud |
    \\-----//              ------------          +-----+     \-----/
    ]]>
        </artwork>
        </figure>
    <t>
    A data center is a physical facility consisting of multiple bays of interconnected servers, that performs computing, storage, and communication needed for cloud services. Infrastructure-as-a-service may be deployed in both public and private clouds, where virtual servers and other virtual resources are made available to users on demand and by self-service.
    </t>
    <t>
    One typical scenario is the intra-city DCs, which communicate with each other via the intra-city DCI network to meet the high availability requirements. The active-active and Virtual Machine (VM) migration services which require low latency are provided by the intra-city DCI network. The intra-city DCI network supports the public and/or the private cloud services, such as video, games, desktop cloud, and cloud Internet cafe services. To ensure low latency, intra-city DCI network is deployed in the same city or adjacent cities. The distance is typically less than 100 km and more likely less than 50km. One city may have several large DCs.
    </t>
    <t>
    DCs are ideally interconnected through Layer 2/3 switches or routers with full mesh connectivity. However, to improve interaction efficiency as well as service experience, OTN is also evaluated as an option to be used for DC interconnection.
    </t>
    <t>
    There are three kinds of the connection relationship, point to point access, single to multiple point access, and multiple to multiple point access. Different types of connections are referring different shapes, single point accessing single cloud, single point accessing multiple clouds and multiple points accessing multiple clouds.
    </t>
   
  </section><!-- Cloud Accessing -->
  <section title="High-quality leased line">
    <t>
    The high quality private line provides high security and reliability and is suitable to ensure the end-to-end user experience for large enterprises such asfinancial, medical centers and education customers. The main advantages and drivers of the high quality private line are as follows.
    </t>
    <t>
    <list style="symbols">
      <t> High quality private lines provide large bandwidth, low latency, secure and reliable for any type of connection.</t> 
      <t> Accelerate the deployment of cloud services. The high-quality and high-security of the private line connecting to the cloud can enable enterprises to move more core assets to the cloud and use low-latency services on the cloud. Cloud-based deployment helps enterprises reduce heavy asset allocation and improve energy saving, so that enterprises can focus on their major business.</t> 
      <t> Reduce operator's CAPEX and OPEX. The end-to-end service provisioning system enables quick provisioning of private line services and improves user experience. Fault management can be done from the device level to reduce the complexity of location.</t> 
      <t> Enable operators to develop value-added services by providing enterprise users with latency maps, availability maps, comprehensive SLA reports, customized latency levels, and dynamic bandwidth adjustment packages.</t>
    </list>
    </t>

   
   </section><!-- High Quality Leased Line -->
   <section title="Cloud virtual reality" toc="default" anchor="cloudvr">
    <t>
    Cloud Virtual Reality (VR) offloads computing and cloud rendering in VR services from local dedicated hardware to a shared cloud infrastructure. Cloud rendered video and audio outputs are encoded, compressed, and transmitted to user terminals through fast and stable networks. In contrast to current VR services, where good user experience primarily relies on the end user purchasing expensive high-end PCs for local rendering, cloud VR promotes the popularization of VR services by allowing users to enjoy various VR services where rendering is carried out in the cloud.
    </t>
    <t>
    Cloud VR service experience is impacted by several factors that influence the achieved sense of reality, interaction, and immersion, which are related to the network properties, e.g. bandwidth, latency and packet loss. The network performance indicators, such as bandwidth, latency, and packet loss rate, need to meet the requirements to realize a pleasurable experience.
    </t>
    
    <t>
    The current network may be able to support early versions of cloud VR (e.g. 4K VR) with limited user experience, but will not meet the requirements for large scale deployment of cloud VR with enhanced experience (e.g. Interactive VR applications, cloud games). To support more applications and ensure a high-quality experience, much higher available and guaranteed bandwidth (e.g. larger than 1 Gbps), lower latency (e.g. less than 10 ms) and lower jitter (e.g. less than 5 ms) are required.
    </t>
   </section><!-- cloudvr -->
 </section><!-- scenario --> 
     
<section title="Requirement and Problem statement" toc="default" anchor="reqps">
  <section title="LxVPN of optical networks for multiple-to-multiple access" toc="default" anchor="access">
  <t>
  To establish MP2MP connections, TDM transport technologies, like OTN, are adopting packet features. Some OTN equipments have adopted packet processing functions, such as packet switching, MPLS VPN, etc., which could provide an underlay performance guaranteed TDM channel for cloud accessing, as an alternative of packet-based connections.
  </t>
  </section> <!-- LxVPN -->
  <section title="Small Granularity Switching" toc="default" anchor="smallgranularity">
  <t>
  Accroding to the ITU-T G.709 recommendation, the OTN is providing TDM based connection with a granularity 1.25Gbps, which is more than the demand for normal user. Most of the leased line is requesting a bandwidth less than 10Mbps, and the request from big enterprises are usually on the level of 100Mbps. Therefore, most of the leased lines are with small granularity in the field.
  </t> 
  <t>
  The SDH was a good complementary of OTN for small granularity solution, but SDH devices are gradually removed from the network due to End of Services. As SDH networks gradually phase out, service providers start to think about how to utilize OTN networks to transmit small-granularity high-value SDH services. The OSU (optical service unit) is proposed to solve the problem.    
  </t>
  <t>At ITU-T, two work items, G.sub1G.sup and G.OSU, have been initiated aiming to enable OTN to support small-granularity services of 2M-1Gb/s. For G.OSU, the general idea is to put small granularity services into OSU containers, and then put OSU containers into OPU payload areas. OSU containers are flagged by Tributary Port Number (TPN) tags located at the overhead of the OSU containers. At the intermediate nodes, OSUs can be switched to different directions based on the TPN tags in the overhead.  Given the development of OSU, the OTN is expected to be able to carry small granularity service and create end-to-end optical connections.
  </t>
  </section> <!-- smallgranularity -->
  <section title="High-performance and high-reliability" anchor="highpr">
    <t>
    To support the above-mentioned applications some of the network properties are critical to promise the Quality of Services (QoS). For instance, high bandwidth (e.g. larger than 1 Gbps), low latency (e.g. no more than 10 ms) and low jitter (e.g. no more than 5 ms), are required for Cloud VR. In addition, small-granularity container is required to improve the efficiency of the networks. 
    </t>
    <t>
    It is also critical to support highly reliable DCI for cloud services. With advanced optical transport network protection and automatic recovery technologies, services can still run properly even fiber cuts occur in the DCI network. Specific protection and restoration schemes are required, to provide high reliability for the networks.
    </t>
   </section><!-- highpr -->
  
   
</section> <!-- ProblemStatement-->

<section title="Manageability Considerations">
    <t>
   TBD.
    </t>
</section>

<section title="Security Considerations">
  <t>
  TBD. </t>
 </section>
<section title="IANA Considerations" anchor="iana">

    <t>This document requires no IANA actions.</t> 
</section>
 <!-- <section title="Acknowledgements">
  <t> This work has been inspired by the French Systematic project CARRIOCAS and especially the contributors I. Hwang, A. Cavalli, M.Lallali and D. Verchere for their work titled Modelling, validation, and verification of PCEP using the IF language.</t>
 </section> -->
</middle>
<back>
  <references title='Normative References'>
   <?rfc include="reference.RFC.2119.xml" ?>
   <?rfc include="reference.RFC.8174.xml" ?>
   </references>
   <references title='Informational References'>
   <?rfc include="reference.I-D.ietf-rtgwg-net2cloud-gap-analysis" ?>
   <?rfc include="reference.I-D.ietf-rtgwg-net2cloud-problem-statement" ?>
  </references>
  
 
</back>
</rfc>
