Huawei Technologies

H1, Xiliu Beipo Village, Songshan Lake Dongguan China zhenghaomian@huawei.com

Huawei Technologies

italo.busi@huawei.com

Futurewei Technologies

aihuaguo.ietf@gmail.com

Telefonica

luismiguel.contrerasmurillo@telefonica.com

Telefonica

oscar.gonzalezdedios@telefonica.com

Nokia

victor.lopez@nokia.com

Nokia

Sergio.belotti@nokia.com

Nokia

Dieter.Beller@nokia.com

Nokia

reza.rokui@nokia.com

CAICT

xuyunbin@caict.ca.cn

China Mobile

zhaoyangyjy@chinamobile.com

CCAMP Working Group The requirement of slicing network resources with desired quality of service is emerging at every network technology, including the Optical Transport Networks (OTN). As a part of the transport network, OTN can 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 and a YANG data model augmentation of the OTN topology model. Additional YANG data model augmentations will be defined in a future version of this draft.

The requirement of slicing network resources with desired quality of service is emerging at every network technology, including the Optical Transport Networks (OTN). As a part of the transport network, OTN can 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 and a YANG data model augmentation of the OTN topology model. Additional YANG data model augmentations will be defined in a future version of this draft.

An OTN slice is an OTN virtual network topology connecting a number of OTN endpoints using a set of shared or dedicated OTN network resources to satisfy specific service level objectives (SLOs). An OTN slice is a technology-specific realization of an IETF network slice in the OTN domain, with the capability of configuring slice resources in the term of OTN technologies. Therefore, all the terms and definitions concerning network slicing as defined in apply to OTN slicing. An OTN slice can span multiple OTN administrative domains, encompassing access links, intra-domain paths, and inter-domain links. An OTN slice may include multiple endpoints, each associated with a set of physical or logical resources, e.g. optical port or time slots, at the termination point (TP) of an access link or inter-domain link at an OTN provider edge (PE) equipment. An end-to-end OTN slice may be composed of multiple OTN segment slices in a hierarchical or sequential (or stitched) combination. illustrates the scope of OTN slices in multi-domain environment.

<- OTN Segment Slice 1 ---> <-- OTN Segment Slice 2 --> +-------------------------+ +-----------------------+ | +-----+ +-------+ | | +-------+ +-----+| +----+ | | OTN | | OTN | | | | OTN | | OTN || +----+ | CE +-+-o PE +-...--+ Borde o--+--+-o Borde +-...--+ PE o+--+ CE | +----+ |/| | | Node |\ | | | Node | | || +----+ |||+-----+ +-------+ ||| | +-------+ +-----+| | ||| OTN Domain 1 ||| | OTN Domain 2 | | |++-----------------------++| +-----------------------+ | | | | | | | +-----+ +------------+ | | | | | | | V V V V V Access OTN Slice Inter-domain Access Link Endpoint Link Link ]]>

OTN slices may be pre-configured by the management plane and presented to the customer via the northbound interface (NBI), or be dynamically provisioned by a higher layer slice controller, e.g. an IETF network slice controller (IETF NSC) through the NBI. The OTN slice is provided by a service provider to a customer to be used as though it was part of the customer’s own networks.

For end business customers (like OTT or 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 in 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 been allocated to them and which could be used to support their leased lines, when needed. Users may formulate policies based on the demand for services and time to schedule the resources from the entire network’s perspective flexibly. 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 a specific time interval to maximize network resource utilization efficiency.

Co-construction and sharing of a network are becoming a popular means among service providers to reduce 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 occupies a certain percentage of the usage rights of the network resources. In this scenario, the network O&M is performed by a certain founder in each region, where the same founder usually deploys an independent management and control system. The other founders of the network use each other’s management and control system to provision services remotely. In this scenario, different founders’ network resources need to be automatically (associated) divided, isolated, and visualized. All founders may share or have independent O&M capabilities, and should be able to perform service- level provisioning in their respective slices.

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 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 use the leased network resources flexibly, 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, flexibly and independently, schedule and maintain physical resources to support their own end-to-end automation using both leased and self-constructed network resources.

Vertical industry slicing is an emerging category of network slicing due to the high demand for 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, the 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.

In an end-to-end network slicing scenario such as 5G network slicing , an IETF network slice provides the required connectivity between other different segments of an end-to-end network slice, such as the Radio Access Network (RAN) and the Core Network (CN) segments, with a specific performance commitment. An IETF network slice could be composed of network slices from multiple technological and administrative domains. An IETF network slice can be realized by using or combining multiple underlying OTN slices with OTN resources, e.g. ODU time slots or ODU containers, to achieve end-to-end slicing across the transport domain.

OTN slices may be abstracted differently depending on the requirement contained in the configuration provided by the slice customer. Whereas the customer requests an OTN slice to provide connectivities between specified endpoints, an OTN slice can be abstracted as a set of endpoint-to-endpoint links, with each link formed by an end-to-end tunnel across the underlying OTN networks. The resources associated with each link of the slice is reserved and commissioned in the underlying physical network upon the completion of configuring the OTN slice and all the links are active. An OTN slice can also be abstracted as an abstract topology when the customer requests the slice to share resources between multiple endpoints and to use the resources on demand. The abstract topology may consist of virtual nodes and virtual links, whose associated resources are reserved but not commissioned across the underlying OTN networks. The customer can later commission resources within the slice dynamically using the NBI provided by the service provider. An OTN slice could use abstract topology to connect endpoints with shared resources to optimize the resource utilization, and connections can be activated within the slice as needed. It is worth noting that those means to abstract an OTN slice are similar to the Virtual Network (VN) abstraction defined for higher-level interfaces in , in which context a connectivity-based slice corresponds to Type 1 VN and a resource-based slice corresponds to Type 2 VN, respectively. A particular resource in an OTN network, such as a port or link, may be sliced with one of the two granularity levels: Link-based slicing, in which a link and its associated link termination points (LTPs) are dedicatedly allocated to a particular OTN slice. Tributary-slot based slicing, in which multiple OTN slices share the same link by allocating different OTN tributary slots in different granularities. Furthermore, an OTN switch is typically fully non-blockable switching at the lowest ODU container granularity, it is desirable to specify just the total number of ODU containers in the lowest granularity (e.g. ODU0), when configuring tributary-slot based slicing on links and ports internal to an OTN network. In multi-domain OTN network scenarios where separate OTN slices are created on each of the OTN networks and are stitched at inter-domain OTN links, it is necessary to specify matching tributary slots at the endpoints of the inter-domain links. In some real network scenarios, OTN network resources including tributary slots are managed explicitly by network operators for network maintenance considerations. Therefore an OTN slice controller shall support configuring an OTN slice with both options. An OTN slice controller (OTN-SC) is a logical function responsible for the life-cycle management of OTN slices instantiated within the corresponding OTN network domains. The OTN-SC provides technology-specific interfaces at its northbound (OTN-SC NBI) to allow a higher-layer slice controller, such as an IETF network slice controller (NSC), or an orchestrator, to request OTN slices with OTN-specific requirements. The OTN-SC interfaces at the southbound using the MDSC-to-PNC interface (MPI) with a Physical Network Controller (PNC) or Multi-Domain Service Orchestrator (MDSC), as defined in the ACTN control framework . The logical function within the OTN-SC is responsible for translating the OTN slice requests into concrete slice realization which can be understood and provisioned at the southbound by the PNC or MDSC. When realizing OTN slices, the OTN-SC may translate a connectivity-based OTN slice into a set of end-to-end tunnels using the Traffic-engineering(TE) tunnel interface defined in . For a resource-based OTN slice, the OTN-SC may translate the abstract topology representing the slice into a colored graph on an abstract TE topology using the TE topology interface defined in . The OTN-SC NBI is technology-specific, while the IETF NSC-NBI is technology- agnostic. An IETF NSC may translate its customer’s technology-agnostic slice request into an OTN slice request and utilize the OTN-SC NBI to realize the IETF network slice. Alternatively, the IETF NSC may translate the slicing request into tunnel or topology configuration commands and communicate directly with the underlying PNC or MDSC to provision the IETF network slice. illustrates the OTN slicing control hierarchy and the positioning of the OTN slicing interfaces.

OTN-SC functionalities may be recursive such that a higher-level OTN-SC may designate the creation of OTN slices to a lower-level OTN-SC in a recursive manner. This scenario may apply to the creation of OTN slices in multi-domain OTN networks, where multiple domain-wide OTN slices provisioned by lower-layer OTN-SCs are stitched to support a multi-domain OTN slice provisioned by the higher-level OTN-SC. Alternatively, the OTN-SC may interface with an MDSC, which in turn interfaces with multiple PNCs through the MPI to realize OTN slices in multi-domain OTN networks without OTN-SC recursion. illustrates both options for OTN slicing in multi-domain.

OTN-SC functionalities are logically independent and may be deployed in different combinations to cater to the realization needs. In reference with the ACTN control framework , an OTN-SC may be deployed - as an independent network function; - together with a Physical Network Controller (PNC) for single-domain or with a Multi-Domain Service Orchestrator (MDSC)for multi-domain; - together with a higher-level network slice controller to support end-to-end network slicing;

For the configuration of connectivity-based OTN slices, existing models such as the TE tunnel interface may be used and no addition is needed. This model is addressing the case for configuring resource-based OTN slices, where the model permits to reserve resources exploiting the common knowledge of an underlying virtual topology between the OTN-SC and the subtended network controller (MDSC or PNC). The slice is configured by marking corresponding link resources on the TE topology received from the underlying MDSC or PNC with a slice identifier and OTN-specific resource requirements, e.g. the number of ODU time slots or the type/number of ODU containers. The MDSC or PNC, based on the marked resources by the OTN-SC, will update the underlying TE topology with new TE link for each of the colored links to keep booked the reserved OTN resources e.g. time slots or ODU containers.

../../../../../nt:link/link-id ]]>

file "ietf-otn-slice@2021-02-22.yang" module ietf-otn-slice { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-otn-slice"; prefix "otnslice"; import ietf-network { prefix "nw"; reference "RFC 8345: A YANG Data Model for Network Topologies"; } import ietf-network-topology { prefix "nt"; reference "RFC 8345: A YANG Data Model for Network Topologies"; } import ietf-te-topology { prefix "tet"; reference "RFC8795: YANG Data Model for Traffic Engineering (TE) Topologies"; } import ietf-otn-topology { prefix "otntopo"; reference "I-D.ietf-ccamp-otn-topo-yang: A YANG Data Model for Optical Transport Network Topology"; } organization "IETF CCAMP Working Group"; contact "WG Web: WG List: Editor: Haomian Zheng Editor: Italo Busi Editor: Aihua Guo Editor: Victor Lopez "; description "This module defines a YANG data model to configure an OTN network slice realization. The model fully conforms to the Network Management Datastore Architecture (NMDA). Copyright (c) 2021 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; revision "2021-02-22" { description "Initial Version"; reference "draft-zheng-ccamp-yang-otn-slicing-01: Framework and Data Model for OTN Network Slicing"; } /* * Groupings */ grouping otn-link-slice-profile { description "Profile of an OTN link slice."; choice otn-slice-granularity { default "link"; description "Link slice granularity."; case link { leaf slice-id { type uint32; description "Slice identifier"; } } case link-resource { list slices { key slice-id; description "List of slices."; leaf slice-id { type uint32; description "Slice identifier"; } choice technology { description "Data plane technology types."; case otn { leaf otn-ts-num { type uint32; description "Number of OTN tributary slots allocated for the slice."; } } } leaf sliced-link-ref { type leafref { path "../../../../../nt:link/nt:link-id"; } config false; description "Relative reference to virtual links generated from this TE link."; } } } } } /* * Augments */ augment "/nw:networks/nw:network/nt:link/tet:te/" + "tet:te-link-attributes" { when "../../../nw:network-types/tet:te-topology/" + "otntopo:otn-topology" { description "Augmentation parameters apply only for networks with OTN topology type."; } description "Augment OTN TE link attributes with slicing profile."; uses otn-link-slice-profile; } } ]]>

TBD.

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.

<Add any security considerations>

<Add any IANA considerations>

3rd Generation Partnership Project (3GPP) Juniper Networks Cisco Systems Inc Volta Networks Juniper Networks Individual Telefonica This document defines a YANG data model for the provisioning and management of Traffic Engineering (TE) tunnels, Label Switched Paths (LSPs), and interfaces. The model is divided into YANG modules that classify data into generic, device-specific, technology agnostic, and technology-specific elements. This model covers data for configuration, operational state, remote procedural calls, and event notifications. This document defines a YANG data model for representing, retrieving, and manipulating Traffic Engineering (TE) Topologies. The model serves as a base model that other technology-specific TE topology models can augment. Old Dog Consulting Independent Juniper Networks Nokia NTT Futurewei Telefonica Juniper Networks This document describes network slicing in the context of networks built from IETF technologies. It defines the term "IETF Network Slice" and establishes the general principles of network slicing in the IETF context. The document discusses the general framework for requesting and operating IETF Network Slices, the characteristics of an IETF Network Slice, the necessary system components and interfaces, and how abstract requests can be mapped to more specific technologies. The document also discusses related considerations with monitoring and security. This document also provides definitions of related terms to enable consistent usage in other IETF documents that describe or use aspects of IETF Network Slices. Traffic Engineered (TE) networks have a variety of mechanisms to facilitate the separation of the data plane and control plane. They also have a range of management and provisioning protocols to configure and activate network resources. These mechanisms represent key technologies for enabling flexible and dynamic networking. The term "Traffic Engineered network" refers to a network that uses any connection-oriented technology under the control of a distributed or centralized control plane to support dynamic provisioning of end-to- end connectivity.Abstraction of network resources is a technique that can be applied to a single network domain or across multiple domains to create a single virtualized network that is under the control of a network operator or the customer of the operator that actually owns the network resources.This document provides a framework for Abstraction and Control of TE Networks (ACTN) to support virtual network services and connectivity services.

This document was prepared using kramdown. Previous versions of this document were prepared using 2-Word-v2.0.template.dot.