]> Futurewei Technologies

aihuaguo.ietf@gmail.com

Telefonica

luismiguel.contrerasmurillo@telefonica.com

Individual

s.belotti.ietf@gmail.com

Ciena

rrokui@ciena.com

CAICT

xuyunbin@caict.ca.cn

China Mobile

zhaoyangyjy@chinamobile.com

Alef Edge

xufeng.liu.ietf@gmail.com

Routing Common Control and Measurement Plane next generation unicorn sparkling distributed ledger 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 defines YANG data models with OTN technology-specific augments deployed at both the north and south bound of the OTN network slice controller. Additional YANG data model augmentations will be defined in a future version of this draft. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Common Control and Measurement Plane Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction 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 defines YANG data models with OTN technology-specific augments deployed at both the north and south bound of the OTN network slice controller. Additional YANG data model augmentations will be defined in a future version of this draft.

Terminology 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 when, and only when, they appear in all capitals, as shown here. The terminology for describing YANG data models is found in .

Prefixes in Data Node Names In this document, names of data nodes and other data model objects are prefixed using the standard prefix associated with the corresponding YANG imported modules, as shown in . Prefixes and Corresponding YANG Modules

Prefix	YANG Module	Reference
yang	ietf-yang-types
inet	ietf-inet-types
nt	ietf-network-topology
nw	ietf-network-topology
tet	ietf-te-topology
ietf-nss	ietf-network-slice-service	[RFCVVVV]
ns-topo	ietf-ns-topo	[RFCWWWW]
otnt	ietf-otn-topology	[RFCYYYY]
l1-types	ietf-layer1-types	[RFCZZZZ]
otns	ietf-otn-slice	[RFCXXXX]
otns-mpi	ietf-otn-slice-mpi	[RFCXXXX]

RFC Editor Note: Please replace VVVV with the RFC number assigned to . Please replace WWWW with the RFC number assigned to . Please replace XXXX with the RFC number assigned to this document. Please replace YYYY with the RFC number assigned to . Please replace ZZZZ with the RFC number assigned to . Please remove this note.

Definition of OTN Slice An OTN slice is an an RFC 9543 Network Slice connecting a number of OTN endpoints using a set of shared or dedicated OTN network resources to satisfy specific service level objectives (SLOs) and Service Level Expectations (SLEs). An OTN slice is a technology-specific realization of the RFC 9543 network slice service 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 Slice <- 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 RFC 9543 network slice controller (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.

Use Cases for OTN Network Slicing

Leased Line Services with OTN 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 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.

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 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 dedicated network with OTN 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.

End-to-end network slicing In an end-to-end network slicing scenario such as 5G network slicing , an RFC 9543 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 RFC 9543 network slice could be composed of network slices from multiple technological and administrative domains. An RFC 9543 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.

Framework for OTN slicing 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 connectivity 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 are 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, and their 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-blocking 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 RFC 9543 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. The presence of OTN-SC provides multiple options for a high-level slice controller or an orchestrator to configure and realize slicing in OTN networks, depending on whether a customer's slice request is technology agnostic or technology specific: Option 1[opt.1]: An IETF NSC receives a technology-agnostic slice request from the IETF NSC NBI and realizes full or part of the slice in OTN networks directly through MPI provided by the PNC or MDSC. The IETF NSC is responsible for mapping a technology-agnostic slicing request into an OTN technology-specific realization. In this option, the OTN-SC is not used. Option 2[opt.2]: An IETF NSC receives a technology-agnostic slice request from the IETF NSC NBI and delegates the request to the OTN-SC through the OTN-SC NBI, which is OTN technology specific. The OTN-SC in turn realizes the slice in single or multi domain OTN networks by working with the underlying PNC or MDSC. In this option, the OTN-SC is considered as a realization of IETF NSC, i.e., an NS realizer as per , when the underlying network is OTN. The OTN-SC is also a subordinate slice controller of the RFC 9543 NSC, which is consistent with the hierarchical control of slices specified by . Option 3[opt.3]: An OTN-aware orchestrator may request an OTN technology-specific slice with OTN-specific SLOs through the OTN-SC NBI to the OTN-SC. The OTN-SC in turn realizes the slice in single or multi domain OTN networks by working with the underlying PNC or MDSC An OTN slice may be realized by using standard MPI interfaces, control plane, network management system (NMS) or any other proprietary interfaces as needed. Examples of such interfaces include the abstract TE topology , TE tunnel ,L1VPN, or Netconf/YANG based interfaces such as OpenConfig. Some of these interfaces, such as the TE tunnel model, are suitable for creating connectivity-based OTN slices which represent a slice as a set of TE tunnels, while other interfaces such as the TE topology model are more suitable for creating resource-based OTN slices which represent a slice as a topology. The OTN-SC NBI is a technology-specific interface that augments the IETF NSC NBI, which is technology- agnostic. illustrates the OTN slicing control hierarchy , the positioning of the OTN slicing interfaces as well as the options for OTN slice configuration.

Positioning of 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 for multi-domain

OTN-SC functionalities are logically independent and may be deployed in different combinations to cater to the realization needs. In reference to 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;

Realizing OTN Slices introduces a mechanism for an RFC 9543 network slice controller to realize network slices by constructing Network Resource Partitions (NRP). A NRP is a collection of resources identified in the underlay network to facilitate the mapping of network slices onto available network resources. An NRP is a scope view of a topology and may be considered as a topology in its own right. Thus, in traffic-engineered (TE) networks including OTN, an NRP may be simply represented as an abstract TE topology defined by . For OTN networks, An NRP may be represented as an abstract OTN topology defined by . The NRP can be used to address scalability challenges that arise when network slices are mapped directly onto the underlay topology, where a large number of control-plane and data-plane states may otherwise need to be instantiated and maintained for each slice. An NRP is internal to the network slice controller, and its use is optional and particularly in OTN transport networks, where resources are already physically partitioned into time slots with corarse granularity than the resources considered in L2-L3 networks. Nevertheless, NRPs can provide significant benefits for slice realization in large-scale environments, including also OTN networks. For connectivity-based OTN slices, a connection within an OTN slice is typically realized by an OTN tunnel in the underlay topology and resources are reserved by the tunnel, thus use of NRP is optional in this case. For resource-based OTN slices, the OTN-SC maps an OTN slice directly onto the underlay TE topology exposed by the subtended controller (MDSC or PNC) without creating separate NRP topology instances. In this case, the OTN-SC configures NRP identifiers on the relevant underlay link resources. An NRP identifier represents a resource partition with ODU time slots for tracking slice resource associations. The OTN-SC may then push the topology with configured NRP identifiers to the subtended MDSC or PNC using the MPI model defined in this draft, and subsequently instantiate OTN TE tunnels utilizing the related underlay link resources with the appropriate NRP identifier. Multiple OTN slices may be mapped to the same NRP, while any individual connectivity construct of a slice is mapped to only one NRP, as specified in . The resources of an NRP topology are reserved and shared among all OTN slices mapped to the same NRP. illustrates the relationship between OTN slices and NRPs. In this example, Slice 1 and Slice 2 are associated with NRP-1, while Slice 3 is associated with NRP-2. The relevant link resources allocated to each NRP are marked with their corresponding NRP identifiers.

Mapping OTN Slices to NRP

YANG Data Model for OTN Slicing Configuration

OTN Slicing YANG Model for MPI

MPI YANG Model Overview For the realization of connectivity-based OTN slices, the OTN-SC configures an OTN tunnel using the OTN tunnel model and specifies the associated NRP identifier. For the realization of resource-based OTN slices, the OTN-SC configures the NRP by marking the relevant link resources on the TE topology received from the MDSC or PNC with an NRP identifier, together with the appropriate OTN-specific resource attributes, such as the number of ODU time slots or the type and quantity of ODU containers. Based on the resources marked by the OTN-SC, the MDSC or PNC updates the underlay TE topology by creating new TE links corresponding to the reserved OTN resources and keeping those resources booked for the slice.

MPI YANG Model Tree

OTN slicing MPI tree diagram

MPI YANG Code

OTN slicing MPI YANG model WG List: Editor: Haomian Zheng Editor: Italo Busi Editor: Aihua Guo Editor: Sergio Belotti "; description "This module defines a YANG data model for network slice realization in Optical Transport Networks (OTN). The model fully conforms to the Network Management Datastore Architecture (NMDA). Copyright (c) 2022 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 Revised 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 "2025-07-03" { description "Latest revision of MPI YANG model for OTN slicing."; reference "draft-ietf-ccamp-yang-otn-slicing-09: Framework and Data Model for OTN Network Slicing"; } /* * Groupings */ grouping otn-nrp-profile { description "Profile of an OTN link Network Resource Partition (NRP)."; choice otn-nrp-granularity { default "link"; description "Link nrp granularity."; case link { leaf nrp-id { type uint32; description "NRP identifier"; } } case link-resource { list nrps { key nrp-id; description "List of NRPs."; leaf nrp-id { type uint32; description "NRP link resource identifier."; } choice technology { description "Data plane technology types."; case otn { choice nrp-bandwidth { description "Bandwidth specification for an OTN NRP."; case containers { uses l1-types:otn-link-bandwidth; } case time-slots { leaf otn-ts-num { type uint32; description "Number of OTN tributary slots allocated for the NRP."; } } } } } } } } } /* * Augments */ augment "/nw:networks/nw:network/nt:link/tet:te/" + "tet:te-link-attributes" { when "../../../nw:network-types/tet:te-topology/" + "otnt:otn-topology" { description "Augmentation parameters apply only for networks with OTN topology type."; } description "Augment OTN TE link attributes with NRP profile."; uses otn-nrp-profile; } } ]]>

OTN Slicing YANG Model for OTN-SC NBI

NBI YANG Model Overview The YANG model for OTN-SC NBI is OTN-technology specific, but shares many common constructs and attributes with the common network slicing YANG model defined in . Furthermore, the OTN-SC NBI YANG is expected to support both connectivity-based and resource-based slice configuration, which is likely a common requirement for supporting slicing at other transport network layers, e.g. WDM or MPLS(-TP). The OTN slicing model augments the common network slicing YANG model by extending OTN technology-specific SLO and SLE attributes which can be requested by OTN-aware customers and allows the customer to specify desired OTN signal quality. These attributes include:

• The performance objective for Optical Data Unit (ODU) containers as defined in .
• Bandwidth specification in the type and number of ODU containers.

NBI YANG Model Tree for OTN slice

Tree diagram for OTN slice

NBI YANG Code for OTN Slice

YANG model for transport network slice WG List: Editor: Haomian Zheng Editor: Italo Busi Editor: Aihua Guo Editor: Sergio Belotti "; description "This module defines a YANG data model for configuring technology-specific network slices in optical transport networks, e.g., Optical Transport Network (OTN). The model fully conforms to the Network Management Datastore Architecture (NMDA). Copyright (c) 2022 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 Revised 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 "2025-07-03" { description "Latest revision of NBI YANG model for OTN slicing."; reference "draft-ietf-ccamp-yang-otn-slicing-09: Framework and Data Model for OTN Network Slicing"; } /* * Identities */ identity bit-error-rate { base ietf-nss:service-slo-metric-type; description "ODU bit error rate"; } identity odu-tca-threshold-type { description "Base identity for ODU performance counter"; } identity odu-bbe { base odu-tca-threshold-type; description "ODU Background Block Error (BBE) threshold"; } identity odu-es { base odu-tca-threshold-type; description "ODU Errored Seconds (ES) threshold"; } identity odu-ses { base odu-tca-threshold-type; description "ODU Severely Errored Seconds (SES) threshold"; } identity odu-uas { base odu-tca-threshold-type; description "ODU Unavailable Seconds (UAS) threshold"; } identity odu-ber { base odu-tca-threshold-type; description "ODU Bit Error Rate (BER) threshold"; } identity pm-duration { description "Base identity for ODU performance monitoring interval"; } identity pm-15m { base pm-duration; description "15 minuites pm duration"; } identity pm-24h { base pm-duration; description "24 hours pm duration"; } /* * Groupings */ grouping odu-signal-quality { description "Grouping for ODU signal quality."; container odu-signal-quality { description "Contianer for ODU signal quality attributes."; list odu-pm-objective { key "duration pm-type"; description "List of ODU performance requirements."; leaf duration { type identityref { base pm-duration; } description "Time duration."; } leaf pm-type { type identityref { base odu-tca-threshold-type; } description "ODU PM metric type."; } leaf pm-threshold { type uint64; description "ODU PM metric threshold."; } } } } grouping otn-slice-slo-policy { description "Policy grouping for OTN network slices."; container otn { description "OTN technology-specific SLO/SLE policy container"; uses odu-signal-quality; uses l1-types:otn-link-bandwidth; } } /* * Augmented data nodes */ /* slice template */ augment "/ietf-nss:network-slice-services" + "/ietf-nss:slo-sle-templates" + "/ietf-nss:slo-sle-template" + "/ietf-nss:slo-policy" { description "Augment IETF network slice service templates with OTN technology-specific SLO/SLE policy attributes."; uses otn-slice-slo-policy; } /* slice augments */ augment "/ietf-nss:network-slice-services" + "/ietf-nss:slice-service" + "/ietf-nss:slo-sle-policy" + "/ietf-nss:custom" + "/ietf-nss:service-slo-sle-policy" + "/ietf-nss:slo-policy" { description "Augment IETF network slice services to include technology- specific SLO/SLE policy for connectivity-based OTN slices."; uses otn-slice-slo-policy; } /* network topology augments */ augment "/nw:networks/nw:network" + "/ns-topo:slo-sle-policy" + "/ns-topo:custom" + "/ns-topo:service-slo-sle-policy" + "/ns-topo:slo-policy" { when "../../nw:network-types/ns-topo:network-slice" { description "Augment only for Network Slice topology."; } description "Augment topology configuration and state."; uses otn-slice-slo-policy; } /* network node augments */ augment "/nw:networks/nw:network/nw:node" + "/ns-topo:slo-sle-policy" + "/ns-topo:custom" + "/ns-topo:service-slo-sle-policy" + "/ns-topo:slo-policy" { when "../../../nw:network-types/ns-topo:network-slice" { description "Augment only for Network Slice topology."; } description "Augment node configuration and state."; uses otn-slice-slo-policy; } /* network node's termination point augments */ augment "/nw:networks/nw:network/nw:node" + "/nt:termination-point" + "/ns-topo:slo-sle-policy" + "/ns-topo:custom" + "/ns-topo:service-slo-sle-policy" + "/ns-topo:slo-policy" { when "../../../../nw:network-types/ns-topo:network-slice" { description "Augment only for Network Slice topology."; } description "Augment node configuration and state."; uses otn-slice-slo-policy; } /* network link augments */ augment "/nw:networks/nw:network/nt:link" + "/ns-topo:slo-sle-policy" + "/ns-topo:custom" + "/ns-topo:service-slo-sle-policy" + "/ns-topo:slo-policy" { when "../../../nw:network-types/ns-topo:network-slice" { description "Augment only for Network Slice topology."; } description "Augment link configuration and state."; uses otn-slice-slo-policy; } /* connectivity construct augments */ augment "/ietf-nss:network-slice-services" + "/ietf-nss:slice-service" + "/ietf-nss:connection-groups" + "/ietf-nss:connection-group" + "/ietf-nss:slo-sle-policy" + "/ietf-nss:custom" + "/ietf-nss:service-slo-sle-policy" + "/ietf-nss:slo-policy" { description "Augment IETF network slice services to include technology- specific SLO/SLE policy for connection groups within a connectivity-based transport network slice."; uses otn-slice-slo-policy; } augment "/ietf-nss:network-slice-services" + "/ietf-nss:slice-service" + "/ietf-nss:connection-groups" + "/ietf-nss:connection-group" + "/ietf-nss:connectivity-construct" + "/ietf-nss:slo-sle-policy" + "/ietf-nss:custom" + "/ietf-nss:service-slo-sle-policy" + "/ietf-nss:slo-policy" { description "Augment IETF network slice services to include technology- specific SLO/SLE policy for connectivity-constructs within a connectivity-based transport network slice."; uses otn-slice-slo-policy; } augment "/ietf-nss:network-slice-services" + "/ietf-nss:slice-service" + "/ietf-nss:connection-groups" + "/ietf-nss:connection-group" + "/ietf-nss:connectivity-construct" + "/ietf-nss:type" + "/ietf-nss:a2a" + "/ietf-nss:a2a-sdp" + "/ietf-nss:slo-sle-policy" + "/ietf-nss:custom" + "/ietf-nss:service-slo-sle-policy" + "/ietf-nss:slo-policy" { description "Augment IETF network slice services to include technology- specific SLO/SLE policy for a2a connectivity-constructs within a connectivity-based transport network slice."; uses otn-slice-slo-policy; } } ]]>

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.

Security Considerations The YANG module specified in this document defines a schema for data that is designed to be accessed via network management protocols such as NETCONF or RESTCONF . The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) . The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS . The NETCONF access control model provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. There are a number of data nodes defined in this YANG module that are writable/creatable/deletable (i.e., config true, which is the default). These data nodes may be considered sensitive or vulnerable in some network environments. Write operations (e.g., edit-config) to these data nodes without proper protection can have a negative effect on network operations. Considerations in Section 8 of are also applicable to their subtrees in the module defined in this document. Some of the readable data nodes in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g., via get, get-config, or notification) to these data nodes. Considerations in Section 8 of are also applicable to their subtrees in the module defined in this document.

IANA Considerations It is proposed to IANA to assign new URIs from the "IETF XML Registry" as follows: This document registers two YANG modules in the YANG Module Names registry .

References Normative References 3rd Generation Partnership Project (3GPP) ITU Telecommunication Standardization Sector (ITU-T) In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols. This document describes the syntax and semantics of version 1.1 of the YANG language. YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification. There are a small number of backward incompatibilities from YANG version 1. This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF). This document introduces a collection of common data types to be used with the YANG data modeling language. This document obsoletes RFC 6021. This document defines an abstract (generic, or base) YANG data model for network/service topologies and inventories. The data model serves as a base model that is augmented with technology-specific details in other, more specific topology and inventory data models. 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. Huawei Technologies Huawei Technologies Ciena Cisco Systems, Inc Cisco Systems, Inc This document defines a YANG data model for RFC 9543 Network Slice Service. The model can be used in the Network Slice Service interface between a customer and a provider that offers RFC 9543 Network Slice Services. Individual Telefonica Nokia Futurewei Huawei An RFC 9543 network slice customer may utilize intent-based topologies to express resource reservation intentions within the provider's network. These customer-defined intent topologies allow customers to request shared resources for future connections that can be flexibly allocated and customized. Additionally, they provide an extensive level of control over underlay service paths within the network slice. This document describes a YANG data model for expressing customer intent topologies which can be used to enhance the RFC 9543 Network Slice Services in specific use cases, such as Network wholesale scenarios, where both topology and connectivity intents need to be expressed. Huawei Technologies Huawei Technologies Individual Nokia Telefonica This document defines a YANG data model for representing, retrieving, and manipulating Optical Transport Network (OTN) topologies. It is independent of control plane protocols and captures topological and resource-related information pertaining to OTN. Huawei Technologies Huawei Technologies This document defines a collection of common data types, identities, and groupings in the YANG data modeling language. These derived common data types, identities, and groupings are intended to be imported by modules that model Layer 1 configuration and state capabilities. The Layer 1 types are representative of Layer 1 client signals applicable to transport networks, such as Optical Transport Networks (OTN). The Optical Transport Network (OTN) data structures are included in this document as Layer 1 types. A Virtual Network (VN) is a network provided by a service provider to a customer for the customer to use in any way it wants as though it were a physical network. This document provides a YANG data model generally applicable to any mode of VN operations. This includes VN operations as per the Abstraction and Control of TE Networks (ACTN) framework (RFC 8453). 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. Telefonica Ciena Nvidia Huawei Individual This document describes an approach for structuring the IETF Network Slice Controller as well as how to use different data models being defined for IETF Network Slice Service provision (and how they are related). It is not the purpose of this document to standardize or constrain the implementation of the IETF Network Slice Controller. Cisco Systems Inc Cisco Systems Inc Alef Edge Juniper Networks Individual 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 covers data pertinent to TE tunnels, TE LSPs, and TE interfaces that are independent of any technology or dataplane encapsulation. The model is divided into two YANG modules that address both device-specific and device-independent data, supporting configuration, operational state, Remote Procedure Calls (RPCs), and event notifications. This document provides a framework and service level requirements for Layer 1 Virtual Private Networks (L1VPNs). This framework is intended to aid in developing and standardizing protocols and mechanisms to support interoperable L1VPNs. The document examines motivations for L1VPNs, high level (service level) requirements, and outlines some of the architectural models that might be used to build L1VPNs. This memo provides information for the Internet community. The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK] This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol (NETCONF). This document describes a method for invoking and running the Network Configuration Protocol (NETCONF) within a Secure Shell (SSH) session as an SSH subsystem. This document obsoletes RFC 4742. [STANDARDS-TRACK] This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. The standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) or the RESTCONF protocol requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability. There is a need for standard mechanisms to restrict NETCONF or RESTCONF protocol access for particular users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. This document defines such an access control model. This document obsoletes RFC 6536. This document describes an IANA maintained registry for IETF standards which use Extensible Markup Language (XML) related items such as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Description Framework (RDF) Schemas. YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK] Informative References This document describes network slicing in the context of networks built from IETF technologies. It defines the term "IETF Network Slice" to describe this type of 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 the mapping of abstract requests 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.

Acknowledgments This document was prepared using kramdown. Previous versions of this document were prepared using 2-Word-v2.0.template.dot. The authors would like to thank Adrian Farrel, Danielle Ceccarelli, Igor Bryskin, Bo Wu, Gyan Mishra, Joel M. Halpen, Dhruv Dhoddy and Loa Andersson for providing valuable insights.

Contributors Huawei Technologies

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

Huawei Technologies

italo.busi@huawei.com

Telefonica

oscar.gonzalezdedios@telefonica.com

Nokia

victor.lopez@nokia.com

Nokia

Dieter.Beller@nokia.com

Huawei Technologies Canada

henry.yu@huawei.com

China Mobile

sunjiang@chinamobile.com