One document matched: draft-zhang-ccamp-l1-topo-yang-05.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-ccamp-l1-topo-yang-05" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" xml:lang="en">
<front>
<title abbrev="ODU topology YANG model"> A YANG Data Model for Optical Transport Network Topology </title>
<author fullname="Xian Zhang" initials="X." surname="Zhang">
<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 initials="A." surname="Sharma" fullname="Anurag Sharma">
<organization>Infinera</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<email>ansharma@infinera.com</email>
</address>
</author>
<author initials="X." surname="Liu" fullname="Xufeng Liu">
<organization>Ericsson</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<email>xufeng.liu@ericsson.com</email>
</address>
</author>
<date month="October" day="26" year="2016" />
<workgroup>CCAMP 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 transparently across the server-layer network resources. A transport network can be constructed from equipments utilizing any of a number of different transport technologies such as the evolving Optical Transport Networks (OTN) or packet transport as provided by the MPLS-Transport Profile (MPLS-TP).
</t>
<t>
This draft 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 via a REST interface, for OTN topology related operations such as
obtaining the relevant topology resource information.
</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 for a client-layer network to carry the client traffic transparently across the server-layer network resources. A transport network can be constructed of equipments utilizing any of a number of different transport technologies such as the Optical Transport Networks (OTN) or packet transport as provided by the MPLS-Transport Profile (MPLS-TP).
</t>
<t>
This document defines a data model of an OTN network topology, using YANG [RFC6020]. The model can be used by an application exposing to a transport controller via a REST interface. Furthermore, it can be used by an application for the following purposes (but not limited to):
<list style="symbols">
<t>
To obtain a whole view of the network topology information of its interest;
</t>
<t>
To receive notifications with regard to the information change of the OTN topology;
</t>
<t>
To enforce the establishment and update of a network topology with the characteristic specified in the data model, e.g., by a client controller;
</t>
</list>
</t>
<t>
The YANG model defined in this draft is independent of control plane protocols and captures topology related information pertaining to an Optical Transport Networks (OTN)-electrical layer, as the scope specified by <xref target="RFC7062" pageno="false" format="default" /> and <xref target="RFC7138" pageno="false" format="default" />. Furthermore, it is not a stand-alone model, but augmenting from the TE topology YANG model defined in <xref target="I-D.ietf-teas-yang-te-topo" pageno="false" format="default" />.
</t>
<t>
Optical network technologies, including fixed Dense Wavelength Switched Optical Network (WSON) and flexible optical networks (a.k.a., flexi-grid networks), are covered in <xref target="I-D.ietf-ccamp-wson-yang" pageno="false" format="default" /> and <xref target="I-D.vergara-ccamp-flexigrid-yang" pageno="false" format="default" />, respectively.
</t>
</section>
<!-- Introduction
-->
<section title="Terminology and Notations" 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.
</t>
<t>
<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 and Notation
-->
<section anchor="DM" title="YANG Data Model for OTN Topology" toc="default">
<section anchor="tree" title="the YANG Tree" toc="default">
<t>
<figure anchor="treefigure" title="" suppress-title="true" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height="">
<![CDATA[
module: ietf-otn-topology
augment /nd:networks/nd:network/nd:network-types/tet:te-topology:
+--rw otn-topology!
augment /nd:networks/nd:network:
+--rw name? string
augment /nd:networks/nd:network/nd:node:
+--rw name? string
augment /nd:networks/nd:network/lnk:link/tet:te/tet:config:
+--rw available-odu-info* [priority]
| +--rw priority uint8
| +--rw odulist* [odu-type]
| +--rw odu-type identityref
| +--rw number? uint16
+--rw distance? uint32
augment /nd:networks/nd:network/lnk:link/tet:te/tet:state:
+--ro available-odu-info* [priority]
| +--ro priority uint8
| +--ro odulist* [odu-type]
| +--ro odu-type identityref
| +--ro number? uint16
+--ro distance? uint32
augment /nd:networks/nd:network/nd:node/lnk:termination-point
/tet:te/tet:config:
+--rw client-facing? empty
+--rw tpn? uint16
+--rw tsg? identityref
+--rw protocol-type? identityref
+--rw adaptation-type? adaptation-type
+--rw sink-adapt-active? boolean
+--rw source-adapt-active? boolean
+--rw tributaryslots
| +--rw values* uint8
+--rw supported-payload-types* [index]
+--rw index uint16
+--rw payload-type? string
augment /nd:networks/nd:network/nd:node/lnk:termination-point/
tet:te/tet:state:
+--ro client-facing? empty
+--ro tpn? uint16
+--ro tsg? identityref
+--ro protocol-type? identityref
+--ro adaptation-type? adaptation-type
+--ro sink-adapt-active? boolean
+--ro source-adapt-active? boolean
+--ro tributaryslots
| +--ro values* uint8
+--ro supported-payload-types* [index]
+--ro index uint16
+--ro payload-type? string
]]>
</artwork>
</figure>
</t>
</section>
<!-- tree
-->
<section anchor="explanation" title="Explanation of the OTN Topology Data Model" toc="default">
<t>
As can be seen, from the data tree shown in Section 3.1, the YANG module presented in this draft augments from a more generic Traffic Engineered (TE) network topology data model, i.e., the ietf-te-topology.yang as specified in <xref target="I-D.ietf-teas-yang-te-topo" pageno="false" format="default" />. The entities and their attributes, such as node, termination points and links, are still applicable for describing an OTN topology and the model presented in this draft only specifies with technology-specific attributes/information. For example, if the data plane complies with ITU-T G.709 (2012) standards, the switching-capability and encoding attributes MUST be filled as OTN-TDM and G.709 ODUk(Digital Path) respectively.
</t>
<t>
Note the model in this draft re-uses some attributes defined in ietf-transport-types.yang, which is specified in <xref target="I-D.sharma-ccamp-otn-service-model" pageno="false" format="default" />.
</t>
<t>
One of the main augmentations in this model is that it allows to specify the type of ODU container and the number a link can support per priority level. For example, for a ODU3 link, it may advertise 32*ODU0, 16*ODU1, 4*ODU2 available, assuming only a single priority level is supported. If one of ODU2 resource is taken to establish a ODU path, then the availability of this ODU link is updated as 24*ODU0, 12*ODU1, 3*ODU2 available. If there are equipment hardware limitations, then a subset of potential ODU type SHALL be advertised. For instance, an ODU3 link may only support 4*ODU2.
</t>
</section>
<!-- explanation
-->
<section anchor="code" title="The YANG Code" toc="default">
<figure anchor="TheYANGCode" title="" suppress-title="true" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height="">
<![CDATA[
<CODE BEGINS> file " ietf-otn-topology@2016-10-26.yang"
module ietf-otn-topology {
yang-version 1;
namespace "urn:ietf:params:xml:ns:yang:ietf-otn-topology";
prefix "otntopo";
import ietf-network {
prefix "nd";
}
import ietf-network-topology {
prefix "lnk";
}
import ietf-te-topology {
prefix "tet";
}
import ietf-transport-types {
prefix "tran-types";
}
organization
"Internet Engineering Task Force (IETF) CCAMP WG";
contact
"
WG List: <mailto:ccamp@ietf.org>
ID-draft editor:
Xian ZHANG (zhang.xian@huawei.com);
Anurag Sharma (AnSharma@infinera.com);
";
description
"This module defines a protocol independent Layer 1/ODU
topology data model.";
revision 2016-10-26 {
description
"Initial version.";
reference
"draft-zhang-ccamp-l1-topo-yang-04.txt";
}
/*
typedef
*/
typedef adaptation-type {
type enumeration {
enum CBR {
description "Constant Bit Rate.";
}
enum ATMvp {
description "ATM VP.";
}
enum GFP {
description "Generic Framing Procedure.";
}
enum NULL {
description "NULL";
}
enum PRBS {
description "Pseudo Random Binary Sequence";
}
enum RSn {
description "SDH/SONET section";
}
enum ODUj-21 {
description "ODU payload type 21";
}
enum ETHERNET_PP-OS {
description "ETHERNET_PP-OS, for ODU 2 only";
}
enum CBRx {
description "CBRx(0.. 1.25G), for ODU0 only";
}
enum ODU {
description "Optical Data Unit";
}
}
description
"Defines a type representing the adaptation type
on the termination point.";
}
/*
Groupings
*/
grouping otn-topology-type {
container otn-topology {
presence "indicates a topology type of Optical
Transport Network (OTN)-electrical layer.";
description "otn topology type";
}
description "otn-topology-type";
}
grouping otn-topology-attributes {
leaf name {
type string;
description "the topology name";
}
description "name attribute for otn topology";
}
grouping otn-node-attributes {
description "otn-node-attributes";
leaf name {
type string;
description "a name for this node.";
}
}
grouping otn-link-attributes {
description "otn link attributes";
list available-odu-info{
key "priority";
max-elements "8";
description
"List of ODU type and number on this link";
leaf priority {
type uint8 {
range "0..7";
}
description "priority";
}
list odulist {
key "odu-type";
description
"the list of available ODUs per priority level";
leaf odu-type {
type identityref{
base tran-types:tributary-protocol-type;
}
description "the type of ODU";
}
leaf number {
type uint16;
description "the number of odu type supported";
}
}
}
leaf distance {
type uint32;
description "distance in the unit of kilometers";
}
}
grouping otn-tp-attributes {
description "otn-tp-attributes";
leaf client-facing {
type empty;
description
"if present, it means this tp is a client-facing tp.
adding/dropping client signal flow.";
}
leaf tpn {
type uint16 {
range "0..4095";
}
description
"Tributary Port Number. Applicable in case of mux services.";
reference
"RFC7139: GMPLS Signaling Extensions for Control of Evolving
G.709 Optical Transport Networks.";
}
leaf tsg {
type identityref {
base tran-types:tributary-slot-granularity;
}
description "Tributary slot granularity.";
reference
"G.709/Y.1331, February 2012: Interfaces for the Optical
Transport Network (OTN)";
}
leaf protocol-type {
type identityref {
base tran-types:tributary-protocol-type;
}
description "Protocol type for the Termination Point.";
}
leaf adaptation-type {
type adaptation-type;
description
"This attribute indicates the type of the supported
adaptation function at the termination point.";
reference
"G.874.1, January 2002: Optical transport network (OTN):
Protocol-neutral management information model for the
network element view.";
}
leaf sink-adapt-active {
type boolean;
description
"This attribute allows for activation or deactivation of
the sink adaptation function. The value of TRUE means active.";
reference
"G.874.1, January 2002: Optical transport network (OTN):
Protocol-neutral management information model for the
network element view ";
}
leaf source-adapt-active {
type boolean;
description
"This attribute allows for activation or deactivation of
the sink adaptation function. The value of TRUE
means active.";
reference
"G.874.1, January 2002: Optical transport network (OTN):
Protocol-neutral management information model for
the network element view ";
}
container tributaryslots {
description
"A list of tributary slots used by the ODU
Termination Point.";
leaf-list values {
type uint8;
description
"Tributary slot value.";
reference
"G.709/Y.1331, February 2012: Interfaces for the
Optical Transport Network (OTN)";
}
}
list supported-payload-types{
key "index";
description "supported payload types of a TP";
leaf index {
type uint16;
description "payload type index";
}
leaf payload-type {
type string;
description "the payload type supported by this client
tp";
reference
"http://www.iana.org/assignments/gmpls-sig-parameters
/gmpls-sig-parameters.xhtml
not: the payload type is defined as the generalized PIDs
in GMPLS.";
}
}
}
/*
* Data nodes
*/
augment "/nd:networks/nd:network/nd:network-types/tet:te-topology" {
uses otn-topology-type;
description "augment network types to include otn newtork";
}
augment "/nd:networks/nd:network" {
when "nd:network-types/tet:te-topology/otn-topology" {
description "Augment only for otn network";
}
uses otn-topology-attributes;
description "Augment network configuration";
}
augment "/nd:networks/nd:network/nd:node" {
when "../nd:network-types/tet:te-topology/otn-topology" {
description "Augment only for otn network";
}
description "Augment node configuration";
uses otn-node-attributes;
}
augment "/nd:networks/nd:network/lnk:link/tet:te/tet:config" {
when "../../../nd:network-types/tet:te-topology/otn-topology" {
description "Augment only for otn network.";
}
description "Augment link configuration";
uses otn-link-attributes;
}
augment "/nd:networks/nd:network/lnk:link/tet:te/tet:state" {
when "../../../nd:network-types/tet:te-topology/otn-topology" {
description "Augment only for otn network.";
}
description "Augment link state";
uses otn-link-attributes;
}
augment "/nd:networks/nd:network/nd:node/"
+"lnk:termination-point/tet:te/tet:config" {
when "../../../../nd:network-types/tet:te-topology/otn-topology" {
description "Augment only for otn network";
}
description "OTN TP attributes config in a ODU topology.";
uses otn-tp-attributes;
}
augment "/nd:networks/nd:network/nd:node/"
+"lnk:termination-point/tet:te/tet:state" {
when "../../../../nd:network-types/tet:te-topology/otn-topology" {
description "Augment only for otn network";
}
description "OTN TP attributes state in a ODU topology.";
uses otn-tp-attributes;
}
}
<CODE ENDS>
]]>
</artwork>
</figure>
</section>
<!-- YANG CODE
-->
</section>
<!-- DM
-->
<section anchor="IANA" title="IANA Considerations" toc="default">
<t>
TBD.
</t>
</section>
<!-- IANA
-->
<section title="Manageability Considerations" toc="default">
<t>
TBD.
</t>
</section>
<!-- Manageability
-->
<section anchor="Security" title="Security Considerations" toc="default">
<t>
The data following the model defined in this draft is exchanged via, for example, the interface between an orchestrator and a transport network controller. The security concerns mentioned in <xref target="I-D.ietf-teas-yang-te-topo" pageno="false" format="default" /> for using ietf-te-topology.yang model also applies to this draft.
</t>
<t>
The YANG module defined in this document can 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" />.
</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>
Editors 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 Igor Bryskin, Zhe Liu, Dieter Beller and Daniele Ceccarelli for their comments and discussions.
</t>
</section>
<!-- Acknowledgements
-->
<section anchor="Contributor" title="Contributors" toc="default">
<t>
Baoquan Rao
<vspace blankLines="0" />
Huawei Technologies
<vspace blankLines="0" />
Email: raobaoquan@huawei.com
<vspace blankLines="0" />
</t>
<t>
Sergio Belotti
<vspace blankLines="0" />
Alcatel Lucent
<vspace blankLines="0" />
Email: Sergio.belotti@alcatel-lucent.com
<vspace blankLines="0" />
</t>
<t>
Huub van Helvoort
<vspace blankLines="0" />
Hai Gaoming BV
<vspace blankLines="0" />
the Netherlands
<vspace blankLines="0" />
Email: huubatwork@gmail.com
<vspace blankLines="0" />
</t>
</section>
<!-- Contributor
-->
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.I-D.ietf-netmod-rfc6087bis"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.6241.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.6020.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.7138.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.7062.xml"?>
<?rfc include="reference.I-D.ietf-netconf-restconf"?>
<?rfc include="reference.I-D.ietf-teas-yang-te-topo"?>
<?rfc include="reference.I-D.sharma-ccamp-otn-service-model"?>
</references>
<!-- Normative
-->
<references title="Informative References">
<?rfc include="reference.I-D.ietf-ccamp-wson-yang"?>
<?rfc include="reference.I-D.vergara-ccamp-flexigrid-yang"?>
</references>
<!-- Informative
-->
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-24 07:49:42 |