Framework and Data Model for OTN Network SlicingFuturewei Technologiesaihuaguo.ietf@gmail.comTelefonicaluismiguel.contrerasmurillo@telefonica.comNokiaSergio.belotti@nokia.comCienarrokui@ciena.comCAICTxuyunbin@caict.ca.cnChina Mobilezhaoyangyjy@chinamobile.comAlef Edgexufeng.liu.ietf@gmail.comCCAMP Working GroupThe 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.IntroductionThe 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.TerminologyThe 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 NamesIn 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 .PrefixYANG ModuleReferenceyangietf-yang-typesinetietf-inet-typesntietf-network-topologynwietf-network-topologytetietf-te-topologyietf-nssietf-network-slice-service[RFCVVVV]ns-topoietf-ns-topo[RFCWWWW]otntietf-otn-topology[RFCYYYY]l1-typesietf-layer1-types[RFCZZZZ]otnsietf-otn-slice[RFCXXXX]otns-mpiietf-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 SliceAn 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 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 SlicingLeased Line Services with OTNFor 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 SharingCo-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 resourcesIn 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 OTNVertical 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 slicingIn 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 slicingOTN 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 MDSCAn 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.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 to the
ACTN control framework , an OTN-SC may be deployedas 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.YANG Data Model for OTN Slicing ConfigurationOTN Slicing YANG Model for MPIMPI YANG Model OverviewFor 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 TreeMPI YANG Code file "ietf-otn-slice-mpi@2025-07-03.yang"
module ietf-otn-slice-mpi {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-otn-slice-mpi";
prefix "otns-mpi";
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 "otnt";
reference
"draft-ietf-ccamp-otn-topo-yang-20:
RFC YYYY: A YANG Data Model for Optical Transport
Network Topology";
}
import ietf-layer1-types {
prefix "l1-types";
reference
"draft-ietf-ccamp-layer1-types-18:
RFC ZZZZ: A YANG Data Model for Layer 1 Types";
}
organization
"IETF CCAMP Working Group";
contact
"WG Web:
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 NBINBI YANG Model OverviewThe 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 sliceNBI YANG Code for OTN Slice file "ietf-otn-slice@2025-07-03.yang"
module ietf-otn-slice {
yang-version 1.1;
namespace
"urn:ietf:params:xml:ns:yang:ietf-otn-slice";
prefix "otns";
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-layer1-types {
prefix "l1-types";
reference
"draft-ietf-ccamp-layer1-types-18:
RFC ZZZZ: A YANG Data Model for Layer 1 Types";
}
import ietf-network-slice-service {
prefix "ietf-nss";
reference
"draft-ietf-teas-ietf-network-slice-nbi-yang-25:
RFC VVVV: A YANG Data Model for the RFC 9543 Network Slice
Service";
}
import ietf-ns-topo {
prefix "ns-topo";
reference
"draft-ietf-teas-network-slice-topology-yang-01:
RFC WWWW: IETF Network Slice Topology YANG Data Model";
}
organization
"IETF CCAMP Working Group";
contact
"WG Web:
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 ConsiderationsTo 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 ConsiderationsThe 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 ConsiderationsIt 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 .3GPP TS 28.530 V15.1.0 Technical Specification Group Services and System Aspects; Management and orchestration; Concepts, use cases and requirements (Release 15)3rd Generation Partnership Project (3GPP)Error performance parameters and objectives for multi-operator international paths within optical transport networks (Amendment 1)ITU Telecommunication Standardization Sector (ITU-T)Key words for use in RFCs to Indicate Requirement LevelsIn 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.Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 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.The YANG 1.1 Data Modeling LanguageYANG 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).Common YANG Data TypesThis document introduces a collection of common data types to be used with the YANG data modeling language. This document obsoletes RFC 6021.A YANG Data Model for Network TopologiesThis 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.YANG Data Model for Traffic Engineering (TE) TopologiesThis 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.A YANG Data Model for the RFC 9543 Network Slice ServiceHuawei TechnologiesHuawei TechnologiesCienaCisco Systems, IncCisco 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.
IETF Network Slice Topology YANG Data ModelAlef EdgeTelefonicaNokiaFutureweiHuawei 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.
A YANG Data Model for Optical Transport Network TopologyHuawei TechnologiesHuawei TechnologiesAlef EdgeNokiaTelefonica 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.
Common YANG Data Types for Layer 1 NetworksHuawei TechnologiesHuawei Technologies This document defines a collection of common common data types,
identities, and groupings in the YANG data modeling language. These
derived common 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 YANG Data Model for Virtual Network (VN) OperationsA 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).Framework for Abstraction and Control of TE Networks (ACTN)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.IETF Network Slice Controller and its Associated Data ModelsTelefonicaCienaNvidiaHuawei 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 the IETF Network Slice Controller.
A YANG Data Model for Traffic Engineering Tunnels, Label Switched Paths, and InterfacesCisco Systems IncCisco Systems IncAlef EdgeJuniper NetworksIndividual 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 that is independent of
any technology or dataplane encapsulation and is divided into two
YANG modules that cover device-specific, and device independent data.
This model covers data for configuration, operational state, remote
procedural calls, and event notifications.
Framework and Requirements for Layer 1 Virtual Private NetworksThis 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.Network Configuration Protocol (NETCONF)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]RESTCONF ProtocolThis 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).Using the NETCONF Protocol over Secure Shell (SSH)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]The Transport Layer Security (TLS) Protocol Version 1.3This 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.Network Configuration Access Control ModelThe 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.The IETF XML RegistryThis 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 - A Data Modeling Language for the Network Configuration Protocol (NETCONF)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]A Framework for Network Slices in Networks Built from IETF TechnologiesThis 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.AcknowledgmentsThis 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.ContributorsHuawei TechnologiesH1, Xiliu Beipo Village, Songshan LakeDongguanChinazhenghaomian@huawei.comHuawei Technologiesitalo.busi@huawei.comTelefonicaoscar.gonzalezdedios@telefonica.comNokiavictor.lopez@nokia.comNokiaDieter.Beller@nokia.comHuawei Technologies Canadahenry.yu@huawei.comChina Mobilesunjiang@chinamobile.com