CCAMP Working Group H. Zheng
Internet-Draft Z. Fan
Intended status: Standards Track Huawei Technologies
Expires: May 3, 2018 A. Sharma
Google
X. Liu
Jabil
S. Belotti
Nokia
Y. Xu
CAICT
L. Wang
China Mobile
O. Gonzalez de Dios
Telefonica
October 30, 2017
A YANG Data Model for Optical Transport Network Topology
draft-ietf-ccamp-otn-topo-yang-02
Abstract
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).
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 via a REST interface, for
OTN topology related operations such as obtaining the relevant
topology resource information.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Zheng, et al. Expires May 3, 2018 [Page 1]
Internet-Draft OTN Topology YANG Model October 2017
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 3, 2018.
Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology and Notations . . . . . . . . . . . . . . . . . . 3
3. YANG Data Model for OTN Topology . . . . . . . . . . . . . . 4
3.1. the YANG Tree . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Explanation of the OTN Topology Data Model . . . . . . . 4
3.3. The YANG Code . . . . . . . . . . . . . . . . . . . . . . 5
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
5. Manageability Considerations . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction
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
Zheng, et al. Expires May 3, 2018 [Page 2]
Internet-Draft OTN Topology YANG Model October 2017
Transport Networks (OTN) or packet transport as provided by the MPLS-
Transport Profile (MPLS-TP).
This document defines a data model of an OTN network topology, using
YANG [RFC7950]. 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):
o To obtain a whole view of the network topology information of its
interest;
o To receive notifications with regard to the information change of
the OTN topology;
o To enforce the establishment and update of a network topology with
the characteristic specified in the data model, e.g., by a client
controller;
The YANG model defined in this document 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 [RFC7062] and [RFC7138]. Furthermore, it is not a
stand-alone model, but augmenting from the TE topology YANG model
defined in [I-D.ietf-teas-yang-te-topo]. Following TE topology YANG
model, the YANG model defined in this document is interface
independent. The applicability of models to interfaces is described
in [I-D.zhang-teas-actn-yang].
Optical network technologies, including fixed Dense Wavelength
Switched Optical Network (WSON) and flexible optical networks
(a.k.a., flexi-grid networks), are covered in
[I-D.ietf-ccamp-wson-yang] and [I-D.vergara-ccamp-flexigrid-yang],
respectively.
2. Terminology and Notations
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 document is defined in
[I-D.ietf-netmod-yang-tree-diagrams]. They are provided below for
reference.
o Brackets "[" and "]" enclose list keys.
o Abbreviations before data node names: "rw" means configuration
(read-write) and "ro" state data (read-only).
Zheng, et al. Expires May 3, 2018 [Page 3]
Internet-Draft OTN Topology YANG Model October 2017
o Symbols after data node names: "?" means an optional node, "!"
means a presence container, and "*" denotes a list and leaf-list.
o Parentheses enclose choice and case nodes, and case nodes are also
marked with a colon (":").
o Ellipsis ("...") stands for contents of subtrees that are not
shown.
3. YANG Data Model for OTN Topology
3.1. the YANG Tree
module: ietf-otn-topology
augment /nw:networks/nw:network/nw:network-types/tet:te-topology:
+--rw otn-topology!
augment /nw:networks/nw:network/nt:link/tet:te
/tet:te-link-attributes:
+--rw available-odu-info* [priority]
| +--rw priority uint8
| +--rw odulist* [odu-type]
| | +--rw odu-type identityref
| | +--rw number? uint16
| | +--rw tpn-range? string
| +--rw ts-range? string
+--rw tsg? identityref
+--rw distance? uint32
augment /nw:networks/nw:network/nw:node/nt:termination-point
/tet:te:
+--rw supported-payload-types* [index]
+--rw index uint16
+--rw payload-type? string
3.2. Explanation of the OTN Topology Data Model
As can be seen, from the data tree shown in Section 3.1, the YANG
module presented in this document augments from a more generic
Traffic Engineered (TE) network topology data model, i.e., the ietf-
te-topology.yang as specified in [I-D.ietf-teas-yang-te-topo]. 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 document only specifies with technology-
specific attributes/information. For example, if the data plane
complies with ITU-T G.709 (2012) standards, the switching-capability
Zheng, et al. Expires May 3, 2018 [Page 4]
Internet-Draft OTN Topology YANG Model October 2017
and encoding attributes MUST be filled as OTN-TDM and G.709
ODUk(Digital Path) respectively.
Note the model in this document re-uses some attributes defined in
ietf-transport-types.yang, which is specified in
[I-D.ietf-ccamp-otn-tunnel-model].
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.
3.3. The YANG Code
<CODE BEGINS> file "ietf-otn-topology@2017-10-30.yang"
module ietf-otn-topology {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-otn-topology";
prefix "otntopo";
import ietf-network {
prefix "nw";
}
import ietf-network-topology {
prefix "nt";
}
import ietf-te-topology {
prefix "tet";
}
import ietf-otn-types {
prefix "otn-types";
}
organization
"IETF CCAMP Working Group";
contact
"WG Web: <http://tools.ietf.org/wg/ccamp/>
Zheng, et al. Expires May 3, 2018 [Page 5]
Internet-Draft OTN Topology YANG Model October 2017
WG List: <mailto:ccamp@ietf.org>
Editor: Haomian Zheng
<mailto:zhenghaomian@huawei.com>
Editor: Zheyu Fan
<mailto:fanzheyu2@huawei.com>
Editor: Anurag Sharma
<mailto:ansha@google.com>
Editor: Xufeng Liu
<mailto:Xufeng_Liu@jabil.com>
Editor: Sergio Belotti
<mailto:sergio.belotti@nokia.com>
Editor: Yunbin Xu
<mailto:xuyunbin@ritt.cn>
Editor: Lei Wang
<mailto:wangleiyj@chinamobile.com>
Editor: Oscar Gonzalez de Dios
<mailto:oscar.gonzalezdedios@telefonica.com>";
description
"This module defines a protocol independent Layer 1/ODU topology
data model.";
revision 2017-10-30 {
description
"Revision 0.5";
reference
"draft-ietf-ccamp-otn-topo-yang-02.txt";
}
/*
* Groupings
*/
grouping otn-link-attributes {
description "link attributes for OTN";
list available-odu-info {
key "priority";
max-elements "8";
description "List of ODU type and number on this link";
leaf priority {
Zheng, et al. Expires May 3, 2018 [Page 6]
Internet-Draft OTN Topology YANG Model October 2017
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 otn-types:tributary-protocol-type;
}
description "the type of ODU";
}
leaf number {
type uint16;
description "the number of odu type supported";
}
leaf tpn-range {
type string {
pattern "([1-9][0-9]{0,3}(-[1-9][0-9]{0,3})?"
+ "(,[1-9][0-9]{0,3}(-[1-9][0-9]{0,3})?)*)";
}
description
"A list of available tributary port number range
between 1 and 9999.
For example 1-20,25,50-1000";
reference "RFC 7139: GMPLS Signaling Extensions for Control
of Evolving G.709 Optical Transport Networks";
}
}
leaf ts-range {
type string {
pattern "([1-9][0-9]{0,3}(-[1-9][0-9]{0,3})?"
+ "(,[1-9][0-9]{0,3}(-[1-9][0-9]{0,3})?)*)";
}
description
"A list of available tributary slot range
between 1 and 9999.
For example 1-20,25,50-1000";
reference "RFC 7139: GMPLS Signaling Extensions for Control
of Evolving G.709 Optical Transport Networks";
}
}
leaf tsg {
type identityref {
base otn-types:tributary-slot-granularity;
Zheng, et al. Expires May 3, 2018 [Page 7]
Internet-Draft OTN Topology YANG Model October 2017
}
description "Tributary slot granularity.";
reference
"G.709/Y.1331, February 2016: Interfaces for the
Optical Transport Network (OTN)";
}
leaf distance {
type uint32;
description "distance in the unit of kilometers";
}
}
grouping otn-tp-attributes {
description "tp attributes for OTN";
list supported-payload-types {
key "index";
description
"Supported payload types of a TP. The payload type is defined
as the generalized PIDs in GMPLS.";
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";
}
}
}
/*
* Data nodes
*/
augment "/nw:networks/nw:network/nw:network-types/"
+ "tet:te-topology" {
container otn-topology {
presence "indicates a topology type of Optical Transport
Network (OTN)-electrical layer.";
description "otn topology type";
}
description "augment network types to include otn newtork";
}
augment "/nw:networks/nw:network/nt:link/tet:te/"
+ "tet:te-link-attributes" {
Zheng, et al. Expires May 3, 2018 [Page 8]
Internet-Draft OTN Topology YANG Model October 2017
when "../../../nw:network-types/tet:te-topology/"
+ "otntopo:otn-topology" {
description "Augment only for otn network.";
}
description "Augment link configuration";
uses otn-link-attributes;
}
augment "/nw:networks/nw:network/nw:node/nt:termination-point/"
+ "tet:te" {
when "../../../nw:network-types/tet:te-topology/"
+ "otntopo:otn-topology" {
description "Augment only for otn network";
}
description "OTN TP attributes config in ODU topology.";
uses otn-tp-attributes;
}
}
<CODE ENDS>
4. IANA Considerations
TBD.
5. Manageability Considerations
TBD.
6. Security Considerations
The data following the model defined in this document is exchanged
via, for example, the interface between an orchestrator and a
transport network controller. The security concerns mentioned in
[I-D.ietf-teas-yang-te-topo] for using ietf-te-topology.yang model
also applies to this document.
The YANG module defined in this document can be accessed via the
RESTCONF protocol defined in [RFC8040], or maybe via the NETCONF
protocol [RFC6241].
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.
Zheng, et al. Expires May 3, 2018 [Page 9]
Internet-Draft OTN Topology YANG Model October 2017
Editors note: to list specific subtrees and data nodes and their
sensitivity/vulnerability.
7. Acknowledgements
We would like to thank Igor Bryskin, Zhe Liu, and Daniele Ceccarelli
for their comments and discussions.
8. Contributors
Baoquan Rao
Huawei Technologies
Email: raobaoquan@huawei.com
Xian Zhang
Huawei Technologies
Email: zhang.xian@huawei.com
Huub van Helvoort
Hai Gaoming BV
the Netherlands
Email: huubatwork@gmail.com
Victor Lopez
Telefonica
Email: victor.lopezalvarez@telefonica.com
Yunbo Li
China Mobile
Email: liyunbo@chinamobile.com
Dieter Beller
Nokia
Email: dieter.beller@nokia.com
Yanlei Zheng
China Unicom
Email: zhengyl@dimpt.com
9. References
9.1. Normative References
[I-D.ietf-ccamp-otn-tunnel-model]
zhenghaomian@huawei.com, z., Fan, Z., Sharma, A., Rao, R.,
Belotti, S., Lopezalvarez, V., and Y. Li, "OTN Tunnel YANG
Model", draft-ietf-ccamp-otn-tunnel-model-00 (work in
progress), July 2017.
Zheng, et al. Expires May 3, 2018 [Page 10]
Internet-Draft OTN Topology YANG Model October 2017
[I-D.ietf-teas-yang-te-topo]
Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and
O. Dios, "YANG Data Model for Traffic Engineering (TE)
Topologies", draft-ietf-teas-yang-te-topo-13 (work in
progress), October 2017.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>.
[RFC7138] Ceccarelli, D., Ed., Zhang, F., Belotti, S., Rao, R., and
J. Drake, "Traffic Engineering Extensions to OSPF for
GMPLS Control of Evolving G.709 Optical Transport
Networks", RFC 7138, DOI 10.17487/RFC7138, March 2014,
<https://www.rfc-editor.org/info/rfc7138>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>.
9.2. Informative References
[I-D.ietf-ccamp-wson-yang]
Lee, Y., Dhody, D., Zhang, X., Guo, A., Lopezalvarez, V.,
King, D., Yoon, B., and R. Vilata, "A Yang Data Model for
WSON Optical Networks", draft-ietf-ccamp-wson-yang-08
(work in progress), October 2017.
[I-D.ietf-netmod-yang-tree-diagrams]
Bjorklund, M. and L. Berger, "YANG Tree Diagrams", draft-
ietf-netmod-yang-tree-diagrams-02 (work in progress),
October 2017.
[I-D.vergara-ccamp-flexigrid-yang]
Madrid, U., Perdices, D., Lopezalvarez, V., Dios, O.,
King, D., Lee, Y., and G. Galimberti, "YANG data model for
Flexi-Grid Optical Networks", draft-vergara-ccamp-
flexigrid-yang-05 (work in progress), July 2017.
Zheng, et al. Expires May 3, 2018 [Page 11]
Internet-Draft OTN Topology YANG Model October 2017
[I-D.zhang-teas-actn-yang]
Lee, Y., zhenghaomian@huawei.com, z., Yoon, B., Dios, O.,
Shin, J., and S. Belotti, "Applicability of YANG models
for Abstraction and Control of Traffic Engineered
Networks", draft-zhang-teas-actn-yang-05 (work in
progress), June 2017.
[RFC7062] Zhang, F., Ed., Li, D., Li, H., Belotti, S., and D.
Ceccarelli, "Framework for GMPLS and PCE Control of G.709
Optical Transport Networks", RFC 7062,
DOI 10.17487/RFC7062, November 2013,
<https://www.rfc-editor.org/info/rfc7062>.
Authors' Addresses
Haomian Zheng
Huawei Technologies
F3 R&D Center, Huawei Industrial Base, Bantian, Longgang District
Shenzhen, Guangdong 518129
P.R.China
Email: zhenghaomian@huawei.com
Zheyu Fan
Huawei Technologies
F3 R&D Center, Huawei Industrial Base, Bantian, Longgang District
Shenzhen, Guangdong 518129
P.R.China
Email: fanzheyu2@huawei.com
Anurag Sharma
Google
1600 Amphitheatre Parkway
Mountain View, CA 94043
Email: ansha@google.com
Xufeng Liu
Jabil
Email: Xufeng_Liu@jabil.com
Zheng, et al. Expires May 3, 2018 [Page 12]
Internet-Draft OTN Topology YANG Model October 2017
Sergio Belotti
Nokia
Email: sergio.belotti@nokia.com
Yunbin Xu
CAICT
Email: xuyunbin@ritt.cn
Lei Wang
China Mobile
Email: wangleiyj@chinamobile.com
Oscar Gonzalez de Dios
Telefonica
Email: oscar.gonzalezdedios@telefonica.com
Zheng, et al. Expires May 3, 2018 [Page 13]
