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.comIBM Corporationxufeng.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 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.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 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.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-topologyte-typesietf-te-typesotntietf-otn-topology[RFCYYYY]l1-typesietf-layer1-types[RFCZZZZ]tnsietf-transport-network-sliceRFCXXXXotnsietf-otn-sliceRFCXXXXRFC Editor Note:
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 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.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 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.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 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.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 IETF NSC, which
is consistent with the hierarchical control of slices defined by the IETF network slice framework.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 with 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;YANG Data Model for OTN Slicing ConfigurationOTN Slicing YANG Model for MPIMPI YANG Model OverviewFor 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.MPI YANG Model Tree ../../../../../nt:link/link-id
]]>MPI YANG Code file "ietf-otn-slice@2022-03-04.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-te-topology {
prefix "tet";
reference
"RFC8795: YANG Data Model for Traffic Engineering
(TE) Topologies";
}
import ietf-otn-topology {
prefix "otnt";
reference
"I-D.ietf-ccamp-otn-topo-yang: A YANG Data Model
for Optical Transport Network Topology";
}
import ietf-layer1-types {
prefix "l1-types";
reference
"I-D.ietf-ccamp-layer1-types: 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: Victor Lopez
";
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 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 "2022-03-04" {
description
"Latest revision of MPI YANG model for OTN slicing.";
reference
"draft-ietf-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 {
choice slice-bandwidth {
description
"Bandwidth specification for OTN slices.";
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 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/"
+ "otnt: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;
}
}
]]>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 generic network slicing YANG models.
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).
Therefore, the OTN-SC NBI YANG model is designed into two models, a common base
model for transport network slicing, and an OTN slicing model which augments the
base model with OTN technology-specific constructs.The base model defines a transport network slice (TNS) with the following
constructs and attributes:Common attributes, which include a set of common attributes like slice identifier,
name, description and names of customers who use the slice.Endpoints, which represent conceptual points of connection from a customer
device to the TNS. An endpoint is mapped to specific physical or virtual resources
of the customer and provider, and such mapping is pre-negotiated and known to
both the customer and provider prior to the slice configuration. The mechanism
for endpoint negotiation is outside the scope of this draft.Network topology, which represent set of shared, reserved resources organized as a virtual
topology between all of the endpoints. A customer could use such network topology
to define detailed connecvitiy path traversing the topology, and allow sharing of
resources between its multiple endpoint pairs.Connectivity matrix, which represent the intended virtual connections between the endpoints
within a TNS. A connctivity matrix entry could be associated with an explicit path
over the above network topology.Service-level objectives (SLOs) associated with different objects, including the TNS,
node, link, termination point, and explicit path, within a TNS.NBI YANG Model Tree for Transport Network Slice ../../../node/node-id
| | +--rw source-tp? leafref
| +--rw destination
| +--rw dest-node? -> ../../../node/node-id
| +--rw dest-tp? leafref
+--rw connectivity-matrices
+--rw connectivity-matrix* [connectivity-matrix-id]
+--rw connectivity-matrix-id uint32
+--rw topology-id? leafref
+--rw src-endpoint?
| -> ../../../endpoints/endpoint/endpoint-id
+--rw dst-endpoint?
| -> ../../../endpoints/endpoint/endpoint-id
+--rw slo
+--rw explicit-path* [tp-id]
+--rw tp-id leafref
]]>NBI YANG Code for Transport Network Slice file "ietf-transport-network-slice@2022-03-04.yang"
module ietf-transport-network-slice {
yang-version 1.1;
namespace
"urn:ietf:params:xml:ns:yang:ietf-transport-network-slice";
prefix "tns";
import ietf-inet-types {
prefix inet;
reference
"RFC 6991: Common YANG Data Types";
}
import ietf-te-types {
prefix "te-types";
reference
"RFC 8776: Traffic Engineering Common YANG Types";
}
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 base YANG data model for configuring
generic 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 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 "2022-03-04" {
description
"Latest revision of NBI YANG model for OTN slicing.";
reference
"draft-ietf-ccamp-yang-otn-slicing-01: Framework and Data
Model for OTN Network Slicing";
}
/*
* Identities
*/
identity isolation-level {
description
"Base identity for the isolation-level.";
reference
"GSMA-NS-Template: Generic Network Slice Template,
Version 3.0.";
}
identity no-isolation {
base isolation-level;
description
"Network slices are not separated.";
}
identity physical-isolation {
base isolation-level;
description
"Network slices are physically separated (e.g. different
rack, different hardware, different location, etc.).";
}
identity logical-isolation {
base isolation-level;
description
"Network slices are logically separated.";
}
identity process-isolation {
base physical-isolation;
description
"Process and threads isolation.";
}
identity physical-memory-isolation {
base physical-isolation;
description
"Process and threads isolation.";
}
identity physical-network-isolation {
base physical-isolation;
description
"Process and threads isolation.";
}
identity virtual-resource-isolation {
base logical-isolation;
description
"A network slice has access to specific range of resources
that do not overlap with other network slices
(e.g. VM isolation).";
}
identity network-functions-isolation {
base logical-isolation;
description
"NF (Network Function) is dedicated to the network slice,
but virtual resources are shared.";
}
identity service-isolation {
base logical-isolation;
description
"NSC data are isolated from other NSCs, but virtual
resources and NFs are shared.";
}
/*
* Groupings
*/
grouping ns-generic-info {
description
"Generic configuration of a network slice";
leaf ns-name {
type string;
description
"Name of the specific network slice";
}
leaf ns-description {
type string;
description
"Description regarding the specific network slice";
}
leaf-list customer-name {
type string;
description
"List of customers using the slice";
}
}
grouping ns-slo {
description
"SLO configuration of a network slice";
container slo {
description
"SLO configuration of a network slice";
leaf optimization-criterion {
type identityref {
base te-types:objective-function-type;
}
description
"Optimization criterion applied to this topology.";
}
leaf delay-tolerance {
type boolean;
description
"'true' if is not too critical how long it takes to
deliver the amount of data.";
reference
"GSMA-NS-Template: Generic Network Slice Template,
Version 3.0.";
}
leaf-list periodicity {
type uint64;
units seconds;
description
"A list of periodicities supported by the network
slice.";
reference
"GSMA-NS-Template: Generic Network Slice Template,
Version 3.0.";
}
leaf isolation-level {
type identityref {
base isolation-level;
}
description
"A network slice instance may be fully or partly,
logically and/or physically, isolated from another
network slice instance. This attribute describes
different types of isolation:";
}
}
}
grouping node-slo {
description
"Node SLO";
container slo {
description
"SLO configuration of a node";
leaf isolation-level {
type identityref {
base isolation-level;
}
description
"A network slice instance may be fully or partly,
logically and/or physically, isolated from another
network slice instance. This attribute describes
different types of isolation:";
}
}
}
grouping link-slo {
description
"Link SLO";
container slo {
description
"SLO configuration of a link";
leaf delay-tolerance {
type boolean;
description
"'true' if is not too critical how long it takes to
deliver the amount of data.";
reference
"GSMA-NS-Template: Generic Network Slice Template,
Version 3.0.";
}
leaf-list periodicity {
type uint64;
units seconds;
description
"A list of periodicities supported by the network
slice.";
reference
"GSMA-NS-Template: Generic Network Slice Template,
Version 3.0.";
}
leaf isolation-level {
type identityref {
base isolation-level;
}
description
"A network slice instance may be fully or partly,
logically and/or physically, isolated from another
network slice instance. This attribute describes
different types of isolation:";
}
}
}
grouping connectivity-matrix-slo {
description
"SLO configuration of a path within a network slice";
container slo {
description
"Path SLO configuration";
}
leaf delay-tolerance {
type boolean;
description
"'true' if is not too critical how long it takes to
deliver the amount of data.";
reference
"GSMA-NS-Template: Generic Network Slice Template,
Version 3.0.";
}
leaf-list periodicity {
type uint64;
units seconds;
description
"A list of periodicities supported by the network
slice.";
reference
"GSMA-NS-Template: Generic Network Slice Template,
Version 3.0.";
}
leaf isolation-level {
type identityref {
base isolation-level;
}
description
"A network slice instance may be fully or partly,
logically and/or physically, isolated from another
network slice instance. This attribute describes
different types of isolation:";
}
}
grouping connectivity-matrix-entry-slo {
description
"SLO configuration of a connectivity matrix entry within a
network slice";
container slo {
description
"SLO configuration of a connectivity matrix entry";
}
}
grouping explicit-path {
description
"Explicit path for a connectivity matrix entry";
list explicit-path {
key "tp-id";
description
"List of TPs within a network topology that form a
path.";
leaf tp-id {
type leafref {
path "/network-slices/network-slice[ns-id=current()"+
"/../../../../ns-id]/network-topologies"+
"/network-topology[topology-id=current()"+
"/../../topology-id]/node/termination-point"+
"/tp-id";
}
description
"Relative reference to TP id.";
}
}
}
grouping network-topology-def {
description
"Network topology definition";
list node {
key "node-id";
description
"The inventory of nodes of this topology.";
leaf node-id {
type inet:uri;
description
"Node identifier.";
}
uses node-slo;
list termination-point {
key "tp-id";
description
"TP identifier";
leaf tp-id {
type inet:uri;
description
"Termination point identifier.";
}
leaf endpoint-id {
type leafref {
path "/network-slices/network-slice[ns-id=current()"+
"/../../../../../ns-id]/endpoints/endpoint/"+
"endpoint-id";
}
description
"Relative reference to TP id.";
}
}
}
list link {
key "link-id";
description
"Link identifier.";
leaf link-id {
type inet:uri;
description
"Link identifier.";
}
uses link-slo;
container source {
description
"Link source node";
leaf source-node {
type leafref {
path "../../../node/node-id";
}
description
"Source node identifier, must be in same topology.";
}
leaf source-tp {
type leafref {
path "../../../node[node-id=current()/../"+
"source-node]/termination-point/tp-id";
}
description
"Termination point within source node that terminates
the link.";
}
}
container destination {
description
"Link destination node";
leaf dest-node {
type leafref {
path "../../../node/node-id";
}
description
"Destination node identifier, must be in same
topology.";
}
leaf dest-tp {
type leafref {
path "../../../node[node-id=current()/../"+
"dest-node]/termination-point/tp-id";
}
description
"Termination point within destination node that
terminates the link.";
}
}
}
}
/*
* Configuration data nodes
*/
container network-slices {
description
"Generic network slice configurations";
list network-slice {
key "ns-id";
description
"Network slice identifier";
leaf ns-id {
type string;
description
"A unique network slice identifier across a slice
controller";
}
uses ns-generic-info;
uses ns-slo;
container endpoints {
description
"Endpoints of a network slice";
list endpoint {
key "endpoint-id";
description
"List of endpoints";
leaf endpoint-id {
type string;
description
"Endpoint identifier";
}
}
}
container network-topologies {
description
"A network slice is described as a network topology";
list network-topology {
key "topology-id";
description
"List of network topologies";
leaf topology-id {
type string;
description
"Topology identifier";
}
uses network-topology-def;
}
}
container connectivity-matrices {
description
"Connectivity matrices";
list connectivity-matrix {
key "connectivity-matrix-id";
description
"List of connectivity matrix entities";
leaf connectivity-matrix-id {
type uint32;
description
"Connectivity matrix identifier";
}
leaf topology-id {
type leafref {
path "../../../network-topologies/network-topology"+
"/topology-id";
}
description
"Relative reference to network topology id.";
}
leaf src-endpoint {
type leafref {
path "../../../endpoints/endpoint/endpoint-id";
}
description
"Relative reference to endpoint id.";
}
leaf dst-endpoint {
type leafref {
path "../../../endpoints/endpoint/endpoint-id";
}
description
"Relative reference to endpoint id.";
}
uses connectivity-matrix-entry-slo;
uses explicit-path;
} //connectivity-matrix
} //connectivity-matrices
} //network-slice
} //network slices
}
]]>NBI YANG Model Tree for OTN sliceTBD.NBI YANG Code for OTN SliceTBD.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 a YANG module 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)Generic Network Slice Template, Version 5.0GSMA AssociationKey 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.Common YANG Data Types for Traffic EngineeringThis document defines a collection of common data types and groupings in YANG data modeling language. These derived common types and groupings are intended to be imported by modules that model Traffic Engineering (TE) configuration and state capabilities.A YANG Data Model for Optical Transport Network TopologyHuawei TechnologiesHuawei TechnologiesVolta NetworksNokiaTelefonica This document describes a YANG data model to describe the topologies
of an Optical Transport Network (OTN). It is independent of control
plane protocols and captures topological and resource related
information pertaining to OTN. This model enables clients, which
interact with a transport domain controller, for OTN topology related
operations such as obtaining the relevant topology resource
information.
A YANG Data Model for Layer 1 TypesHuawei TechnologiesHuawei Technologies This document defines a collection of common data types and groupings
in the YANG data modeling language for use with layer 1 networks.
These derived common types and groupings are intended to be imported
by modules that specify OTN networks, such as topology, tunnel,
client signal adaptation and service.
Framework for IETF Network SlicesOld Dog ConsultingIndependentJuniper NetworksCienaNTTFutureweiTelefonicaMicrosoft Inc. 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.
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 modelsTelefonicaNokiaApstraHuaweiVoltaHuaweiNokia This document describes the major functional components of an IETF
Network Slice Controller (NSC) as well as references the data models
required for supporting the requests of IETF network slices and their
realization.
A YANG Data Model for Traffic Engineering Tunnels, Label Switched Paths and InterfacesJuniper NetworksCisco Systems IncVolta NetworksJuniper NetworksIndividualTelefonica 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.
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]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