CCAMP Working Group                                       Haomian Zheng
Internet Draft                                               Italo Busi
Intended status: Standard Track                     Huawei Technologies
                                                              Aihua Guo
                                                 Futurewei Technologies

Expires: May 2021                                      November 2, 2020



             Framework and Data Model for OTN Network Slicing
                   draft-zheng-ccamp-yang-otn-slicing-00


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), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This Internet-Draft will expire on May 2, 2021.

Copyright Notice

   Copyright (c) 2020 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




Zheng, et al.            Expires May 2, 2021                   [Page 1]


Internet-Draft     Framework and YANG of OTN Slices       November 2020


   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.

Abstract

   The requirement of slicing network resource with desired quality of
   service is emerging at every network technology, including the
   Optical Transport Networks (OTN). As a part of the transport network,
   the OTN has the capability to provide hard pipes with guaranteed data
   isolation and deterministic low latency, which are highly demanded in
   the Service Level Agreement (SLA).

   This document describes a framework for OTN network slicing. A YANG
   data model augmentation will be defined in a future version of this
   draft.

Table of Contents

   1. Introduction...................................................2
   2. Use Cases for OTN Network Slicing..............................3
      2.1. Leased Line Services with OTN.............................3
      2.2. Co-construction and Sharing...............................3
      2.3. Wholesale of optical resources............................4
      2.4. Vertical dedicated network with OTN.......................4
   3. Framework for OTN slicing......................................5
   4. YANG Model.....................................................7
   5. YANG Tree......................................................7
   6. Manageability Considerations...................................7
   7. Security Considerations........................................7
   8. IANA Considerations............................................7
   9. References.....................................................7
      9.1. Normative References......................................7
      9.2. Informative References....................................8
   Acknowledgments...................................................8
   Contributors' Addresses...........................................9
   Authors' Addresses................................................9

1. Introduction

   The requirement of slicing network resource with desired quality of
   service is emerging at every network technology, including the
   Optical Transport Networks (OTN). As a part of the transport network,
   the OTN has the capability to provide hard pipes with guaranteed data




Zheng, et al.            Expires May 2, 2021                   [Page 2]


Internet-Draft     Framework and YANG of OTN Slices       November 2020


   isolation and deterministic low latency, which are highly demanded in
   the Service Level Agreement (SLA).

   This document describes a framework for OTN network slicing. A YANG
   data model augmentation will be defined in a future version of this
   draft.

2. Use Cases for OTN Network Slicing

2.1. Leased Line Services with OTN

   For large OTT enterprises, leased lines have the advantage of
   providing high-speed connections with low costs. On the other hand,
   the traffic control of leased lines is very challenging due to rapid
   changes of service demands. Carriers are recommended to provide
   network-level slicing capabilities to meet this demand. Based on such
   capabilities, private network users have full control over the sliced
   resources which have allocated to them and which could be used to
   support their leased lines, when needed. Users may formulate policies
   based on the demand on services and time to flexibly schedule the
   network from the perspective of the entire network. For example, the
   bandwidth between any two points may be established or released based
   on the time or monitored traffic characteristics, the routing and
   bandwidth may be adjusted at specific time interval to maximize
   network resource utilization efficiency.

2.2. Co-construction and Sharing

   Co-construction and sharing of a network is becoming a popular mean
   amongst service providers with the goal of reducing networking
   building capex. For Co-construction and sharing case, there are
   typically multiple co-founders for the same network. For example, one
   founder may provide optical fibres and another founder may provide
   OTN equipment, while each of them occupies a certain percentage of
   the usage rights of the network resources. In this scenario, the
   network O&M is performed by certain founder in each region, where an
   independent management and control system is usually deployed by the
   same founder. The other founders of the network use each other's
   management and control system to provision services remotely. In this
   scenario, network resources used by different founders need to be
   automatically (associated) divided, isolated, and visualized. In
   addition, all founders have independent O&M capabilities, and should
   be able to perform service-level provisioning in their respective
   slices.





Zheng, et al.            Expires May 2, 2021                   [Page 3]


Internet-Draft     Framework and YANG of OTN Slices       November 2020


2.3. Wholesale of optical resources

   In the optical resource wholesale market, smaller, local carriers and
   wireless carriers may rent resources from larger carriers, or
   infrastructure carriers, instead of building their own networks.
   Likewise, international carriers may rent resources from respective
   local carriers and local carriers may lease their owned networks to
   each other to achieve better network utilization efficiency.

   From the perspective of a resource provider, it is crucial that a
   network slice is timely configured to meet traffic matrix
   requirements requested by its tenants. The support for multi-tenancy
   within the resource provider's network demands that the network
   slices are qualitatively isolated from each other to meet the
   requirements for transparency, non-interference, and security.

   Typically, a resource purchaser expects to flexibly use the leased
   network resources just like they are self-constructed.  Therefore,
   the purchaser is not only provided with a network slice, but also the
   full set of functionalities for operating and maintaining the network
   slice.  The purchaser also expects to, in a flexible and independent
   manner, schedule and maintain physical resources to support their own
   end-to-end automation using both leased and self-constructed network
   resources.

2.4. Vertical dedicated network with OTN

   Vertical industry slicing is an emerging category of network slicing
   due to the high demand of private high-speed network interconnects
   for industrial applications.

   In this scenario, the biggest challenge is to implement
   differentiated optical network slices based on the requirements from
   different industries. For example, in the financial industry, to
   support high-frequency transactions, the slice must ensure to provide
   the minimum latency along with the mechanism for latency management.
   For the healthcare industry, online diagnosis network and software
   capabilities to ensure the delivery of HD video without frame loss.
   For bulk data migration in data centers, network needs to support on-
   demand, large-bandwidth allocation. In each of the aforementioned
   vertical industry scenarios, the bandwidth shall be adjusted as
   required to ensure flexible and efficient network resource usage.







Zheng, et al.            Expires May 2, 2021                   [Page 4]


Internet-Draft     Framework and YANG of OTN Slices       November 2020


3. Framework for OTN slicing

   An OTN slice is a collection of OTN network resources that is used to
   establish a logically dedicated OTN virtual network over one or more
   OTN networks. For example, the bandwidth of an OTN slice is described
   in terms of the number/type of OTN time slots; the labels may be
   specified as OTN tributary slots and/or tributary ports to allow
   slice users to interconnect devices with matching specifications.

   The relationship between an OTN slice and an IETF network slice [I-D.
   teas-transport-network-slice-yang] is for further discussions.

   To support the configuration of OTN slices, an OTN slice controller
   (OTN-SC) can be deployed either outside or within the SDN controller.

   In the former case, the OTN-SC translates an OTN slice configuration
   request into a TE topology configuration or a set of TE tunnel
   configurations, and instantiate it by using the TE topology [RFC8795]
   or TE tunnel [I-D.ietf-teas-yang-te] interfaces at the MPI, as
   defined in the ACTN framework [RFC8453].

   In the latter case, an Orchestrator or an end-to-end slice controller
   may request OTN slices directly through the OTN slicing interface
   provided by the OTN-SC. A higher-level OTN-SC may also designate the
   creation of OTN slices to a lower-level OTN-SC in a recursive manner.

   Figure 1 illustrates the OTN slicing control hierarchy and the
   positioning of the OTN slicing interfaces.





















Zheng, et al.            Expires May 2, 2021                   [Page 5]


Internet-Draft     Framework and YANG of OTN Slices       November 2020


                      +--------------------+
                      | Provider's User    |
                      +--------|-----------+
                               |CMI
        +----------------------+---------------------------+
        |         Orchestrator / E2E Slice Controller      |
        +-----------+------------------------------+-------+
                    |OTN-SC NBI                    |
                    |                              |
        +-----------+---------+   OTN-SC NBI       |OTN-SC NBI
        |      OTN-SC         +---------------+    |
        +-----------+---------+               |    |
                    |MPI                      |    |
       +------------|-------------------------|----|--------+
       | SDN        |                 +-------+----+-------+|
       | Controller |                 |      OTN-SC        ||
       |            |                 +-------+------------+|
       |            |                         |Internal API |
       |+-----------+-------------------------+------------+|
       ||                PNC/MDSC                          ||
       |+-----------------------+--------------------------+|
       +------------------------|---------------------------+
                                |SBI
                    +-----------+----------+
                    |OTN Physical Network  |
                    +----------------------+

             Figure 1 - Positioning of OTN Slicing Interfaces

   A particular OTN network resource, such as a port or link, may be
   sliced in two modes:

   o  Link-based slicing, where a link and its associated link
      termination points (LTPs) are dedicatedly allocated to a
      particular OTN network slice.

   o  Tributary-slot based slicing, where multiple OTN network slices
      share the same link by allocating different OTN tributary slots in
      different granularities.

   Additionally, since OTN tributary slots are usually switched
   unconstrained at every node within an OTN network, it is unimportant
   to which exact tributary slot(s) an OTN slice is allocated, but
   rather mattered is the number and type of the tributary slots.





Zheng, et al.            Expires May 2, 2021                   [Page 6]


Internet-Draft     Framework and YANG of OTN Slices       November 2020


4. YANG Model

   TBD. The OTN slice YANG model may augment the IETF network slice YANG
   models, developed in [I-D. teas-transport-network-slice-yang], and/or
   the TE topology defined in [RFC8795].

5. YANG Tree

   TBD.

6. Manageability Considerations

   To ensure the security and controllability of physical resource
   isolation, slice-based independent operation and management are
   required to achieve management isolation.

   Each optical slice typically requires dedicated accounts,
   permissions, and resources for independent access and O&M. This
   mechanism is to guarantee the information isolation among slice
   tenants and to avoid resource conflicts. The access to slice
   management functions will only be permitted after successful security
   checks.

7. Security Considerations

   <Add any security considerations>

8. IANA Considerations

   <Add any IANA considerations>

9. References

9.1. Normative References

   [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for
             Abstraction and Control of TE Networks (ACTN)", RFC 8453,
             DOI 10.17487/RFC8453, August 2018 <https://www.rfc-
             editor.org/info/rfc8453>.

   [RFC8795] Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and
             O. Gonzalez de Dios, "YANG Data Model for Traffic
             Engineering (TE) Topologies", RFC 8795, DOI
             10.17487/RFC8795, August 2020, <https://www.rfc-
             editor.org/info/rfc8795>.




Zheng, et al.            Expires May 2, 2021                   [Page 7]


Internet-Draft     Framework and YANG of OTN Slices       November 2020


   [I-D. teas-transport-network-slice-yang] Liu, X., Tantsura J.,
             Bryskin I., Contreras L., Wu Q., Belotti S., and Rokui R.,
             "Transport Network Slice YANG Data Model", draft-liu-teas-
             transport-network-slice-yang-01 (work in progress), July
             2020.

   [I-D.ietf-teas-yang-te] Saad, T., Gandhi, R., Liu, X., Beeram, V.,
             and I. Bryskin, "A YANG Data Model for Traffic Engineering
             Tunnels and Interfaces", draft-ietf-teas-yang-te-22 (work
             in progress), November 2019.

9.2. Informative References

   TBD

Acknowledgments

   This document was prepared using 2-Word-v2.0.template.dot.































Zheng, et al.            Expires May 2, 2021                   [Page 8]


Internet-Draft     Framework and YANG of OTN Slices       November 2020


Contributors' Addresses

   Henry Yu
   Huawei Technologies Canada

   Email: henry.yu@huawei.com


Authors' Addresses

   Haomian Zheng
   Huawei Technologies
   H1, Xiliu Beipo Village, Songshan Lake,
   Dongguan,
   China

   Email: zhenghaomian@huawei.com


   Italo Busi
   Huawei Technologies

   Email: italo.busi@huawei.com


   Aihua Guo
   Futurewei Technologies

   Email: aihuaguo.ietf@gmail.com




















Zheng, et al.            Expires May 2, 2021                   [Page 9]