One document matched: draft-zhang-teas-transport-service-model-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<!-- vi: set et smarttab sw=2 tabstop=4:-->
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-zhang-teas-transport-service-model-01" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" xml:lang="en">
<front>
<title abbrev="Transport Service Model"> A Service YANG Model for Connection-oriented Transport Networks </title>
<author fullname="Xian Zhang" initials="X." surname="Zhang" role="editor">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>F3-5-B R&D Center, Huawei Industrial Base, Bantian, Longgang District</street>
<city>Shenzhen</city>
<region>Guangdong</region>
<code>518129</code>
<country>P.R.China</country>
</postal>
<email>zhang.xian@huawei.com</email>
</address>
</author>
<author fullname="Jeong-dong Ryoo" initials="J." surname="Ryoo">
<organization>ETRI</organization>
<address>
<postal>
<street> </street>
<city> </city>
<region> </region>
<code> </code>
<country> </country>
</postal>
<email>ryoo@etri.re.kr</email>
</address>
</author>
<date day="31" month="October" year="2016" />
<workgroup>TEAS Working Group</workgroup>
<abstract>
<t>
A transport network is a server-layer network designed to provide connectivity services for a client-layer network to carry the client traffic opaquely across the server-layer network resources. A transport network may be constructed from equipments utilizing any of a number of different transport technologies such as the evolving optical transport infrastructure (Synchronous Optical Networking (SONET) / Synchronous Digital Hierarchy (SDH) and Optical Transport Network (OTN)) or packet transport as epitomized by the MPLS Transport Profile (MPLS-TP).
</t>
<t>
This draft provides a transport service YANG model that can be used together with the RESTCONF protocol for a northbound client to initiate service requests toward the transport network controllers via the RESTful interface between them so as to enable automated service interations.
</t>
</abstract>
<note title="Requirements Language">
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in
<xref target="RFC2119" pageno="false" format="default" />.
</t>
</note>
</front>
<middle>
<section title="Introduction" toc="default">
<t>
A transport network is a server-layer network designed to provide connectivity services, or more advanced services like Virtual Private Networks (VPN) for a client-layer network to carry the client traffic opaquely across the server-layer network resources. It acts as a pipe provider for upper-layer networks, such as IP network and mobile networks.
</t>
<t>
Transport networks, such as Synchronous Optical Networking (SONET) / Synchronous Digital Hierarchy (SDH), Optical Transport Network (OTN), Wavelength Division Multiplexing (WDM), and flexi-grid networks, are often built using equipments from a single vendor and are managed using private interfaces to dedicated Element Management Systems (EMS) / Network Management Systems (NMS). All transport networks have high benchmarks for reliability and operational simplicity. This suggests a common, technology-independent management/control paradigm that is extended to represent and configure specific technology attributes.
</t>
<t>
The YANG language <xref target="RFC6020" pageno="false" format="default" /> is currently the data modeling language of choice within the IETF and has been adopted by a number of industry-wide open management and control initiatives. YANG may be used to model both configuration and operational states; it is vendor-neutral and supports extensible APIs for control and management of elements.
</t>
<t>
This document, exploting the YANG language, provides a transport service model that can be used by a northbound client (e.g., an orchestrator, a client network controller etc.) to initiate service requests, as well as retrieving service states, toward the transport network via the RESTful interface provided by the transport network controller(s). The model is currently scoped for connection-oriented transport networks and connection-less transport networks are out of scope. To understand better what interfaces a service model can apply to in the transport SDN architecture (i.e., Abstract Control of Transport Networks (ACTN))and how service model relates to other YANG models defined in IETF in general, please refer to <xref target="I-D.zhang-teas-actn-yang" pageno="false" format="default" /> for more detailed information.
</t>
</section>
<!-- Introduction
-->
<section title="Terminology" toc="default">
<t>
A simplified graphical representation of the data model is used in this document. The meaning of the symbols in the YANG data tree presented later in this draft is defined in <xref target="I-D.ietf-netmod-rfc6087bis" pageno="false" format="default"/>. They are provided below for reference.
<list style="symbols">
<t>
Brackets "[" and "]" enclose list keys.
</t>
<t>
Abbreviations before data node names: "rw" means configuration (read-write) and "ro" state data (read-only).
</t>
<t>
Symbols after data node names: "?" means an optional node, "!" means a presence container, and "*" denotes a list and leaf-list.
</t>
<t>
Parentheses enclose choice and case nodes, and case nodes are also marked with a colon (":").
</t>
<t>
Ellipsis ("...") stands for contents of subtrees that are not shown.
</t>
</list>
</t>
</section>
<!-- Terminology
-->
<section anchor="Tree" title="Service Model - YANG Tree" toc="default">
<t>
The service model YANG tree is provided below:
</t>
<figure>
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height="">
<![CDATA[
module: ietf-transport-service
+--rw transport_service
+--rw service* [service-name]
+--rw service-name -> ../config/service-name
+--rw config
| +--rw service-name? string
| +--rw service-id? uint32
| +--rw service-endpoints* [node-id tp-id]
| | +--rw type? enumeration
| | +--rw node-id union
| | +--rw tp-id uint32
| | +--rw endpoint-name? string
| +--rw service-type identityref
| +--rw supporting-tunnel
| | +--rw tunnel-name? string
| +--rw bandwidth? decimal64
| +--rw protection-type? identityref
| +--rw constraints
| +--rw delay-limit? uint32
| +--rw delayvariation-limit? uint32
| +--rw packetloss-limit? decimal64
| +--rw objective? identityref
+--ro state
+--ro service-name? string
+--ro service-id? uint32
+--ro service-endpoints* [node-id tp-id]
| +--ro type? enumeration
| +--ro node-id union
| +--ro tp-id uint32
| +--ro endpoint-name? string
+--ro service-type identityref
+--ro supporting-tunnel
| +--ro tunnel-name? string
+--ro bandwidth? decimal64
+--ro protection-type? identityref
+--ro creation-time? ytypes:date-and-time
+--ro constraints
| +--ro delay-limit? uint32
| +--ro delayvariation-limit? uint32
| +--ro packetloss-limit? decimal64
| +--ro objective? identityref
+--ro performance-info
| +--ro delay? uint32
| +--ro delay-variation? uint32
| +--ro packet-loss? decimal64
+--ro oper-status tet:te-oper-status
]]>
</artwork>
</figure>
</section>
<!-- Tree
-->
<section anchor="YANGCode" title="Service Model - YANG Code" toc="default">
<figure>
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height="">
<![CDATA[
<CODE BEGINS>file "ietf-transport-service@2016-10-31.yang"
module ietf-transport-service {
yang-version 1;
namespace "urn:ietf:params:xml:ns:yang:ietf-transport-service";
prefix transservice;
import ietf-inet-types {
prefix inet;
}
import ietf-yang-types {
prefix ytypes;
}
import ietf-te-types {
prefix "tet";
}
organization "Internet Engineering Task Force";
contact
"Editor: Xian ZHANG (zhang.xian@huawei.com)";
description
"this module describes a service module that is an essential
API for a client to ask for a provider network for a path
without the need to care about underlying technologies.
Capability to specify constraints/policies are provided as
optional features.";
revision 2016-10-31 {
description
"Initial revision.";
reference "to add the draft name";
}
grouping endpoints-grouping{
description "end point grouping";
leaf type {
type enumeration {
enum root {
description "root";
}
enum leaf {
description "leaf";
}
enum unknown {
description "unknown";
}
}
default root;
description
"This attribute indicates whether a endpoint of the
service is acting as a root or leaf, and takes on
the value either root, leaf or unkown. If the service
type is Point-to-Point or Multipoint-to-Multipoint,
then the type is equal to root. If the service type
is Point-to-Multipoint, then the type can be either
root or leaf.";
}
leaf node-id {
type union {
type inet:ip-address; //IPv4 or IPv6
type uint32;
}
description
"the node address of a service .";
}
leaf tp-id {
type uint32;
description
"the termination point of a service.";
}
leaf endpoint-name {
type string;
description
"the name of this service endpoint";
}
}
identity service-type {
description
"base identity from which the specific service
type can be derived.";
}
identity service-P2P {
base service-type;
description
"a point-to-point service type";
}
identity service-P2MP {
base service-type;
description
"a point to multi-point type";
}
identity service-MP2MP {
base service-type;
description
"a multi-point to multi-point type";
}
//note: service type such as EPL, EVPL, EPLAN
// EVPLAN, E-Tree can be added when augmenting
// this model.
identity service-prot-type {
description
"base identity from which the specific
protection type can be derived.";
}
identity service-prot-unprotected {
base service-prot-type;
description
"service protection type: unprotected";
}
identity service-prot-1plusR {
base service-prot-type;
description
"service protection type: dynamic reroute";
reference
"draft-ietf-teas-gmpls-resource-sharing-proc-04";
}
identity service-prot-1plus1 {
base service-prot-type;
description
"service protection type: static 1+1";
}
identity service-prot-1plus1plusR {
base service-prot-type;
description
"service protection type: 1+1+R";
reference
"draft-ietf-teas-gmpls-resource-sharing-proc-04";
}
identity objective-type{
description
"base identity from which the specific obective
funciton can be derived.";
}
identity objective-mindelay{
base objective-type;
description
"objective: minimized delay";
}
identity objective-mincost {
base objective-type;
description
"objective: minimized cost";
}
identity objective-mindistance {
base objective-type;
description
"objective: minimized distance";
}
grouping service-config-grouping {
description "service-config-groupoing";
leaf service-name{
type string;
description "the name for a service";
}
leaf service-id {
type uint32;
description
"an unique identificaiton of a service.";
}
list service-endpoints{
key "node-id tp-id";
description
"this provides the service endpoints and it can be used
to support different types of services (including P2P,
MP2MP, P2MP)";
uses endpoints-grouping;
}
leaf service-type {
type identityref {
base service-type;
}
mandatory true;
description
"the type of a service request";
}
container supporting-tunnel {
leaf tunnel-name{
type string;
description "the name of a tunnel (unique)";
}
description
"the tunnels that can be used to support the service";
}
leaf bandwidth {
type decimal64 {
fraction-digits 2;
}
description "the bandwidth requested by a service.";
}
leaf protection-type{
type identityref {
base service-prot-type;
}
description
"the type of protection expected for this
service";
}
}
grouping constraints-grouping {
leaf delay-limit {
type uint32;
description
"Delay variation in micro-seconds.";
}
leaf delayvariation-limit {
type uint32;
description
"Delay variation.";
}
leaf packetloss-limit {
type decimal64 {
fraction-digits 6;
range "0 .. 50.331642";
}
description
"Delay variation in %.";
}
leaf objective {
type identityref
{
base objective-type;
}
description
"objective function imposed for path computation
from this service.";
}
description "constraints gropuing";
}
container transport_service {
description
"serves as a top-level container for a list of services";
list service {
key "service-name";
description
"an unique identifier of a service";
leaf service-name {
type leafref {
path "../config/service-name";
}
description "a unique service identifier.";
}
container config{
description "service config container";
uses service-config-grouping;
container constraints{
uses constraints-grouping;
description
"specify the constraints imposed by a
service";
}
}
container state
{
config false;
description "operational state of a service";
uses service-config-grouping;
leaf creation-time {
type ytypes:date-and-time;
description
"the time when service is created";
}
container constraints{
uses constraints-grouping;
description
"specify the constraints imposed by a
service";
}
container performance-info{
description "service state-performance info";
leaf delay{
type uint32;
description "the latency of this service";
}
leaf delay-variation {
type uint32;
description "the service delay varation";
}
leaf packet-loss {
type decimal64 {
fraction-digits 6;
range "0 .. 50.331642";
}
description "packet loss";
}
}
leaf oper-status {
type tet:te-oper-status;
mandatory true;
description
"the operational status of this service";
}
}//end of state of a service
}//end of service list (including config and state)
}//service top container
}
<CODE ENDS>
]]>
</artwork>
</figure>
</section>
<!-- YANG Code
-->
<section anchor="genConAndFutureItems" title="General Considerations and Some Open Issues" toc="default">
<t>
<xref target='I-D.liu-netmod-yang-schedule'></xref> defines a YANG data model for configuration scheduling. A service model can also be scheduled, therefore the ietf-schedule model can be used to serve this purpose by specifying the appropriate object using xpath.
</t>
<t>
Functions that are under considerations for updating the YANG model:
<list>
<t>
1): Service delivery model augmentation: Information such as PIR/CIR pertaining to ETH service is needed and it is more appropriate to augment the base model; for OTN-based service model, signal-type information needs to be added;
</t>
<t>
2): To add service-related notification, e.g.: service up; service down, service degraded etc.; Currently, there are two options available, one is using the method provided in <xref target='RFC5277'></xref>, the other one is using the new mechanism proposed in <xref target='I-D.ietf-netconf-yang-push'></xref>.
</t>
<t>
3): To figure out how to deal with attributes such as bandwidth, schedule where it can be per node for non-P2P, but is per node pair for P2P;
</t>
<t>
4): to add XRO/IRO constraints;
</t>
</list>
</t>
</section>
<!-- Issues
-->
<section anchor="iana" title="IANA Considerations" toc="default">
<t> TBD. </t>
</section>
<!-- IANA
-->
<section title="Manageability Considerations" toc="default">
<t>TBD</t>
</section>
<section anchor="Security" title="Security Considerations" toc="default">
<t>
Since the data model defined in this draft is manipulated via, for example, the interface between an orchestrator and a transport network controller. The YANG module defined in this draft is designed to be accessed via the RESTCONF protocol defined in <xref target="I-D.ietf-netconf-restconf" pageno="false" format="default" />, or maybe via the NETCONF protocol <xref target="RFC6241" pageno="false" format="default" />. As mentioned in Security Conserations Section of <xref target="I-D.ietf-netconf-restconf" pageno="false" format="default" /> that HTTPS defined in <xref target="RFC7230" pageno="false" format="default" /> can be used to provide security while accessing data.
</t>
<t>
There are a number of data nodes defined in the YANG module which 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., POST) to these data nodes without proper protection can have a negative effect on network operations.
</t>
<t> Editor note: to List specific subtrees and data nodes and their sensitivity/vulnerability.</t>
</section>
<!-- Security
-->
<section anchor="Acknowledgements" title="Acknowledgements" toc="default">
<t> We would like to thank Baoquan Rao and Gang Xie for their initial discussions that trigger the generation of this draft. We would also like to thank Michael Scharf from Nokia for very useful comments to this draft and the model.</t>
<t>
Aspects of the work in this Internet-Draft is funded by the UK Engineering and Physical Sciences Research Council (EPSRC) under the TOUCAN project (EP/L020009/1).
</t>
</section>
<!-- Acknowledgements
-->
<section anchor="Contributor" title="Contributors" toc="default">
<t>
Zhe Liu
<vspace blankLines="0" />
Huawei Technologies
<vspace blankLines="0" />
Email: liuzhe123@huawei.com
<vspace blankLines="0" />
</t>
<t>
Sergio Belotti
<vspace blankLines="0" />
Nokia
<vspace blankLines="0" />
Email:sergio.belotti@nokia.com
<vspace blankLines="0" />
</t>
<t>
Daniel King
<vspace blankLines="0" />
Lancaster University
<vspace blankLines="0" />
Email:d.kindg@lancaster.ac.uk
<vspace blankLines="0" />
</t>
</section>
<!-- Contributor
-->
</middle>
<back>
<references title="Normative References">
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.6020.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?>
<?rfc include="reference.I-D.draft-ietf-netconf-restconf-13.xml" ?>
<?rfc include="reference.I-D.draft-ietf-netmod-rfc6087bis-06.xml" ?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.7230.xml"?>
<?rfc include="reference.I-D.draft-liu-netmod-yang-schedule-02.xml" ?>
</references>
<!-- Normative
-->
<references title="Informative References">
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.6241.xml"?>
<?rfc include="reference.I-D.draft-zhang-teas-actn-yang-02.xml"?>
<?rfc include="reference.I-D.draft-ietf-teas-yang-te-03.xml" ?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5277.xml"?>
<?rfc include="reference.I-D.draft-ietf-netconf-yang-push-04.xml" ?>
</references>
<!-- Informative
-->
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-24 13:03:09 |