draft-ietf-ccamp-optical-impairment-topology-yang-02.txt   draft-ietf-ccamp-optical-impairment-topology-yang-03.txt 
CCAMP Working Group Y. Lee
Internet Draft SKKU (Sung Kyun Kwan University)
Intended Status: Standard Track
Expires: May 7, 2020 V. Lopez
Telefonica
G. Galimberti
Cisco
Jean Luc Auge
Orange
D. Beller
Nokia
November 4, 2019 CCAMP Working Group Y. Lee
Internet-Draft SKKU (Sung Kyun Kwan University)
A Yang Data Model for Optical Impairment-aware Topology Intended status: Standards Track V. Lopez
Expires: September 10, 2020 Telefonica
G. Galimberti
Cisco
D. Beller
Nokia
March 9, 2020
draft-ietf-ccamp-optical-impairment-topology-yang-02 A Yang Data Model for Optical Impairment-aware Topology
draft-ietf-ccamp-optical-impairment-topology-yang-03
Abstract Abstract
In order to provision an optical connection through optical In order to provision an optical connection through optical networks,
networks, a combination of path continuity, resource availability, a combination of path continuity, resource availability, and
and impairment constraints must be met to determine viable and impairment constraints must be met to determine viable and optimal
optimal paths through the network. The determination of appropriate paths through the network. The determination of appropriate paths is
paths is known as Impairment-Aware Routing and Wavelength Assignment known as Impairment-Aware Routing and Wavelength Assignment (IA-RWA)
(IA-RWA) for WSON, while it is known as Impairment-Aware Routing and for WSON, while it is known as Impairment-Aware Routing and Spectrum
Spectrum Assigment (IA-RSA) for SSON. Assigment (IA-RSA) for SSON.
This document provides a YANG data model for the impairment-aware TE This document provides a YANG data model for the impairment-aware TE
topology in optical networks. topology in optical networks.
Status of this Memo Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with This Internet-Draft is submitted to IETF in full conformance with the
the provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. Drafts is at https://datatracker.ietf.org/drafts/current/.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at Internet-Drafts are draft documents valid for a maximum of six months
http://www.ietf.org/shadow.html 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 7, 2020. This Internet-Draft will expire on September 10, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with carefully, as they describe your rights and restrictions with respect
respect to this document. Code Components extracted from this to this document. Code Components extracted from this document must
document must include Simplified BSD License text as described in include Simplified BSD License text as described in Section 4.e of
Section 4.e of the Trust Legal Provisions and are provided without the Trust Legal Provisions and are provided without warranty as
warranty as described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction ................................................ 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology ............................................ 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Tree diagram ........................................... 4 1.2. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Prefixes in Data Node Names............................. 4 1.3. Prefixes in Data Node Names . . . . . . . . . . . . . . . 4
2. Reference Architecture....................................... 5 2. Reference Architecture . . . . . . . . . . . . . . . . . . . 4
2.1. Control Plane Architecture.............................. 5 2.1. Control Plane Architecture . . . . . . . . . . . . . . . 5
2.2. Transport Data Plane.................................... 6 2.2. Transport Data Plane . . . . . . . . . . . . . . . . . . 6
2.3. OMS Media Links......................................... 7 2.3. OMS Media Links . . . . . . . . . . . . . . . . . . . . . 6
2.3.1. Optical Tributary Signal (OTSi) ................... 7 2.3.1. Optical Tributary Signal (OTSi) . . . . . . . . . . . 7
2.3.2. Optical Tributary Signal Group (OTSiG) ............ 8 2.3.2. Optical Tributary Signal Group (OTSiG) . . . . . . . 7
2.3.3. Media Channel Group (MCG) ........................ 10 2.3.3. Media Channel (MC) . . . . . . . . . . . . . . . . . 8
2.4. Amplifiers ............................................ 11 2.3.4. Media Channel Group (MCG) . . . . . . . . . . . . . . 9
2.5. Transponders .......................................... 11 2.4. Amplifiers . . . . . . . . . . . . . . . . . . . . . . . 10
2.6. WSS/Filter ............................................ 12 2.5. Transponders . . . . . . . . . . . . . . . . . . . . . . 11
2.7. Optical Fiber ......................................... 12 2.6. WSS/Filter . . . . . . . . . . . . . . . . . . . . . . . 11
3. YANG Model (Tree Structure)................................. 17 2.7. Optical Fiber . . . . . . . . . . . . . . . . . . . . . . 11
4. Optical Impairment Topology YANG Model ..................... 19 2.8. ROADM Node Architectures . . . . . . . . . . . . . . . . 12
5. Security Considerations..................................... 38 2.8.1. Integrated ROADM Architecture with Integrated Optical
6. IANA Considerations ........................................ 38 Transponders . . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgments ............................................ 39 2.8.2. Integrated ROADMs with Integrated Optical
8. References ................................................. 40 Transponders and Single Channel Add/Drop Interfaces
8.1. Normative References................................... 40 for Remote Optical Transponders . . . . . . . . . . . 13
8.2. Informative References................................. 40 2.8.3. Disaggregated ROADMs Subdivided into Degree,
9. Contributors ............................................... 42 Add/Drop, and Optical Transponder Subsystems . . . . 14
Authors' Addresses ............................................ 42 2.8.4. Optical Impairments Imposed by ROADM Nodes . . . . . 15
3. YANG Model (Tree Structure) . . . . . . . . . . . . . . . . . 17
4. Optical Impairment Topology YANG Model . . . . . . . . . . . 20
5. Security Considerations . . . . . . . . . . . . . . . . . . . 53
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 54
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 54
8.1. Normative References . . . . . . . . . . . . . . . . . . 54
8.2. Informative References . . . . . . . . . . . . . . . . . 54
Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 56
Appendix B. Additional Authors . . . . . . . . . . . . . . . . . 57
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 58
1. Introduction 1. Introduction
In order to provision an optical connection (an optical path) In order to provision an optical connection (an optical path) through
through a wavelength switched optical networks (WSONs) or spectrum a wavelength switched optical networks (WSONs) or spectrum switched
switched optical networks (SSONs), a combination of path continuity, optical networks (SSONs), a combination of path continuity, resource
resource availability, and impairment constraints must be met to availability, and impairment constraints must be met to determine
determine viable and optimal paths through the network. The viable and optimal paths through the network. The determination of
determination of appropriate paths is known as Impairment-Aware appropriate paths is known as Impairment-Aware Routing and Wavelength
Routing and Wavelength Assignment (IA-RWA) [RFC6566] for WSON, while Assignment (IA-RWA) [RFC6566] for WSON, while it is known as IA-
it is known as IA-Routing and Spectrum Assigment (IA-RSA) for SSON. Routing and Spectrum Assigment (IA-RSA) for SSON.
This document provides a YANG data model for the impairment-aware This document provides a YANG data model for the impairment-aware
Traffic Engineering (TE) topology in WSONs and SSONs. The YANG model Traffic Engineering (TE) topology in WSONs and SSONs. The YANG model
described in this document is a WSON/SSON technology-specific Yang described in this document is a WSON/SSON technology-specific Yang
model based on the information model developed in [RFC7446] and the model based on the information model developed in [RFC7446] and the
two encoding documents [RFC7581] and [RFC7579] that developed two encoding documents [RFC7581] and [RFC7579] that developed
protocol independent encodings based on [RFC7446]. protocol independent encodings based on [RFC7446].
The intent of this document is to provide a Yang data model, which The intent of this document is to provide a Yang data model, which
can be utilized by a Multi-Domain Service Coordinator (MDSC) to can be utilized by a Multi-Domain Service Coordinator (MDSC) to
collect states of WSON impairment data from the Transport PNCs to collect states of WSON impairment data from the Transport PNCs to
enable impairment-aware optical path computation according to the enable impairment-aware optical path computation according to the
ACTN Architecture [RFC8453]. The communication between controllers ACTN Architecture [RFC8453]. The communication between controllers
is done via a NETCONF [RFC8341] or a RESTCONF [RFC8040]. Similarly, is done via a NETCONF [RFC8341] or a RESTCONF [RFC8040].
this model can also be exported by the MDSC to a Customer Network Similarly,this model can also be exported by the MDSC to a Customer
Controller (CNC), which can run an offline planning process to map Network Controller (CNC), which can run an offline planning process
latter the services in the network. to map latter the services in the network.
This document augments the generic TE topology draft [TE-TOPO] where This document augments the generic TE topology draft
possible. [I-D.ietf-teas-yang-te-topo] where possible.
This document defines one YANG module: ietf-optical-impairment- This document defines one YANG module: ietf-optical-impairment-
topology (Section 3) according to the new Network Management topology (Section 3) according to the new Network Management
Datastore Architecture [RFC8342]. Datastore Architecture [RFC8342].
1.1. Terminology 1.1. Terminology
Refer to [RFC6566], [RFC7698], and [G.807] for the key terms used in Refer to [RFC6566], [RFC7698], and [G.807] for the key terms used in
this document. this document.
The following terms are defined in [RFC7950] and are not redefined The following terms are defined in [RFC7950] and are not redefined
here: here:
o client o client
o server
o server o augment
o data model
o augment o data node
o data model
o data node
The following terms are defined in [RFC6241] and are not redefined The following terms are defined in [RFC6241] and are not redefined
here: here:
o configuration data o configuration data
o state data o state data
The terminology for describing YANG data models is found in The terminology for describing YANG data models is found in
[RFC7950]. [RFC7950].
1.2. Tree diagram 1.2. Tree Diagram
A simplified graphical representation of the data model is used in A simplified graphical representation of the data model is used in
Section 2 of this this document. The meaning of the symbols in Section 2 of this this document. The meaning of the symbols in these
these diagrams is defined in [RFC8340]. diagrams is defined in [RFC8340].
1.3. Prefixes in Data Node Names 1.3. Prefixes in Data Node Names
In this document, names of data nodes and other data model objects In this document, names of data nodes and other data model objects
are prefixed using the standard prefix associated with the are prefixed using the standard prefix associated with the
corresponding YANG imported modules, as shown in Table 1. corresponding YANG imported modules, as shown in Table 1.
+------------------+----------------------------------+------------+ +--------------+--------------------------+-------------------------+
| Prefix | YANG module | Reference | | Prefix | YANG module | Reference |
+------------------+----------------------------------+------------+ +--------------+--------------------------+-------------------------+
| optical-imp-topo | ietf-optical-impairment-topology | [RFCXXXX] | | optical-imp- | ietf-optical-impairment- | [RFCXXXX] |
| layer0-types | ietf-layer0-types | [L0-Types] | | topo | topology | |
| nw | ietf-network | [RFC8345] | | layer0-types | ietf-layer0-types | [I-D.ietf-ccamp-layer0- |
| nt | ietf-network-topology | [RFC8345] | | | | types] |
| tet | ietf-te-topology | [TE-TOPO] | | nw | ietf-network | [RFC8345] |
+------------------+----------------------------------+------------+ | nt | ietf-network-topology | [RFC8345] |
| tet | ietf-te-topology | [I-D.ietf-teas-yang-te- |
| | | topo] |
+--------------+--------------------------+-------------------------+
Table 1: Prefixes and corresponding YANG modules Table 1: Prefixes and corresponding YANG modules
Note: The RFC Editor will replace XXXX with the number assigned to [Editor's note: The RFC Editor will replace XXXX with the number
the RFC once this draft becomes an RFC. assigned to the RFC once this draft becomes an RFC.]
2. Reference Architecture
2.1. Control Plane Architecture 2. Reference Architecture
2.1. Control Plane Architecture
Figure 1 shows the control plane architecture. Figure 1 shows the control plane architecture.
+--------+ +--------+
| MDSC | | MDSC |
+--------+ +--------+
Scope of this ID -------> || Scope of this ID -------> ||
| || | ||
| +------------------------+ | +------------------------+
| | OPTICAL | | | OPTICAL |
+---------+ | | DOMAIN | +---------+ +---------+ | | DOMAIN | +---------+
| Device | | | CONTROLLER | | Device | | Device | | | CONTROLLER | | Device |
| config. | | +------------------------+ | config. | | config. | | +------------------------+ | config. |
+---------+ v // || \\ +---------+ +---------+ v // || \\ +---------+
______|______ // || \\ ______|______ ______|______ // || \\ ______|______
/ OT \ // || \\ / OT \ / OT \ // || \\ / OT \
| +--------+ |// __--__ \\| +--------+ | | +--------+ |// __--__ \\| +--------+ |
| |Vend. A |--|----+ ( ) +----|--| Vend. A| | | |Vend. A |--|----+ ( ) +----|--| Vend. A| |
| +--------+ | | ~-( )-~ | | +--------+ | | +--------+ | | ~-( )-~ | | +--------+ |
| +--------+ | +---/ \---+ | +--------+ | | +--------+ | +---/ \---+ | +--------+ |
| |Vend. B |--|--+ / \ +--|--| Vend. B| | | |Vend. B |--|--+ / \ +--|--| Vend. B| |
| +--------+ | +---( OLS Segment )---+ | +--------+ | | +--------+ | +---( OLS Segment )---+ | +--------+ |
| +--------+ | +---( )---+ | +--------+ | | +--------+ | +---( )---+ | +--------+ |
| |Vend. C |--|--+ \ / +--|--| Vend. C| | | |Vend. C |--|--+ \ / +--|--| Vend. C| |
| +--------+ | +---\ /---+ | +--------+ | | +--------+ | +---\ /---+ | +--------+ |
| +--------+ | | ~-( )-~ | | +--------+ | | +--------+ | | ~-( )-~ | | +--------+ |
| |Vend. D |--|----+ (__ __) +----|--| Vend. D| | | |Vend. D |--|----+ (__ __) +----|--| Vend. D| |
| +--------+ | -- | +--------+ | | +--------+ | -- | +--------+ |
\_____________/ \_____________/ \_____________/ \_____________/
^ ^ ^ ^
| | | |
| | | |
Scope of [I-D.ietf-ccamp-dwdm-if-param-yang]
Scope of draft-ietf-ccamp-dwdm-if-param-yang
Figure 1. Control Plane Architecture Figure 1: Scope of draft-ietf-ccamp-dwdm-if-param-yang
The models developed in this document is an abstracted Yang model The models developed in this document is an abstracted Yang model
that may be used in the interfaces between the MDSC and the Optical that may be used in the interfaces between the MDSC and the Optical
Domain Controller (aka MPI) and between the Optical Domain Domain Controller (aka MPI) and between the Optical Domain Controller
Controller and the Optical Device (aka SBI) in Figure 1. It is not and the Optical Device (aka SBI) in Figure 1. It is not intended to
intended to support a detailed low-level DWDM interface model. DWDM support a detailed low-level DWDM interface model. DWDM interface
interface model is supported by the models presented in [draft-ietf- model is supported by the models presented in
ccamp-dwdm-if-parameter-yang]. [I-D.ietf-ccamp-dwdm-if-param-yang].
2.2. Transport Data Plane 2.2. Transport Data Plane
This section provides the description of the reference optical This section provides the description of the reference optical
network architecture and its relevant components to support optical network architecture and its relevant components to support optical
impairment-aware path computation. impairment-aware path computation.
Figure 2 shows the reference architecture. Figure 2 shows the reference architecture.
+-------------------+ +-------------------+ +-------------------+ +-------------------+
| ROADM Node | | ROADM Node | | ROADM Node | | ROADM Node |
| | | | | | | |
| PA +-------+ BA | ILA | PA +-------+ BA | | PA +-------+ BA | ILA | PA +-------+ BA |
| +-+ | WSS/ | +-+ | _____ +--+ _____ | +-+ | WSS/ | +-+ | | +-+ | WSS/ | +-+ | _____ +--+ _____ | +-+ | WSS/ | +-+ |
| +-+ | | +-+ | +--+ | +-+ | | +-+ | --|-| |-|Filter |-| |-|-()____)-| |-()____)-|-| |-|Filter |-| |-|--
| +-------+ | optical | +-------+ | | +-+ | | +-+ | +--+ | +-+ | | +-+ |
| | | | | fiber | | | | | | +-------+ | optical | +-------+ |
| | | | | | | | | | | | | | | fiber | | | | |
| o-o-o | | o-o-o | | o o o | | o o o |
| transponders | | transponders | | transponders | | transponders |
+-------------------+ +-------------------+ +-------------------+ +-------------------+
OTS Link OTS Link OTS Link OTS Link
--------> --------> <---------> <--------->
OMS Link
OMS Link <-------------------------------->
---------------------------------->
PA: Pre-Amplifier PA: Pre-Amplifieror
BA: Booster Amplifier BA: Booster Amplifier
ILA: In-Line Amplifier ILA: In-Line Amplifier
Figure 2. Reference Architecture for Optical Transport Network Figure 2: Reference Architecture for Optical Transport Network
BA (on the left side ROADM) is the ingress Amplifier and PA (on the BA (on the left side ROADM) is the ingress Amplifier and PA (on the
right side ROADM is the egress amplifier for the OMS link shown in right side ROADM is the egress amplifier for the OMS link shown in
the Figure. Figure 2.
2.3. OMS Media Links 2.3. OMS Media Links
According to [G.872], OMS Media Link represents a media link between According to [G.872], OMS Media Link represents a media link between
two ROADMs. Specifically, it originates at the ROADM's Filter in the two ROADMs. Specifically, it originates at the ROADM's Filter in the
source ROADM and terminates at the ROADM's Filter in the destination source ROADM and terminates at the ROADM's Filter in the destination
ROADM. ROADM.
OTS Media Link represents a media link: OTS Media Link represents a media link:
(i) between ROADM's BA and ILA;
(ii) between a pair of ILAs;
(iii) between ILA and ROADM's PA.
OMS Media link can be decomposed in a sequence of OTS links type (i) between ROADM's BA and ILA;
(i), (ii), and (iii) as discussed above. OMS Media link would give (ii) between a pair of ILAs;
an abstracted view of impairment data (e.g., power, OSNR, etc.) to (iii) between ILA and ROADM's PA.
the network controller.
OMS Media link can be decomposed in a sequence of OTS links type (i),
(ii), and (iii) as discussed above. OMS Media link would give an
abstracted view of impairment data (e.g., power, OSNR, etc.) to the
network controller.
For the sake of optical impairment evaluation OMS Media link can be For the sake of optical impairment evaluation OMS Media link can be
also decomposed in a sequence of elements such as BA, fiber section, also decomposed in a sequence of elements such as BA, fiber section,
ILA, concentrated loss and PA. ILA, concentrated loss and PA.
2.3.1. Optical Tributary Signal (OTSi) [Editor's note: text below related to [G.807] needs to be revised!
[G.807] is now in publication process.]
2.3.1. Optical Tributary Signal (OTSi)
The OTSi is defined in ITU-T Recommendation G.959.1, section 3.2.4 The OTSi is defined in ITU-T Recommendation G.959.1, section 3.2.4
[G.959.1]. The YANG model defined below assumes that a single OTSi [G.959.1]. The YANG model defined below assumes that a single OTSi
consists of a single modulated optical carrier. This single consists of a single modulated optical carrier. This single
modulated optical carrier conveys digital information. modulated optical carrier conveys digital information.
Characteristics of the OTSi signal are modulation scheme (e.g. QPSK, Characteristics of the OTSi signal are modulation scheme (e.g. QPSK,
8-QAM, 16-QAM, etc.), baud rate (measure of the symbol rate), pulse 8-QAM, 16-QAM, etc.), baud rate (measure of the symbol rate), pulse
shaping (e.g. raised cosine - complying with the Nyquist inter shaping (e.g. raised cosine - complying with the Nyquist inter symbol
symbol interference criterion), etc. interference criterion), etc.
2.3.2. Optical Tributary Signal Group (OTSiG) 2.3.2. Optical Tributary Signal Group (OTSiG)
The definition of the OTSiG is currently being moved from ITU-T The definition of the OTSiG is currently being moved from ITU-T
Recommendation G.709 [G.709] to the new draft Recommendation G.807 Recommendation G.709 [G.709] to the new draft Recommendation G.807
(still work in progress) [G.807]. The OTSiG is an electrical signal (still work in progress) [G.807]. The OTSiG is an electrical signal
that is carried by one or more OTSi's. The relationship between the that is carried by one or more OTSi's. The relationship between the
OTSiG and the the OTSi's is described in ITU-T draft Recommendation OTSiG and the the OTSi's is described in ITU-T draft Recommendation
G.807, section 10.2 [G.807]. The YANG model below supports both G.807, section 10.2 [G.807]. The YANG model below supports both
cases: the single OTSi case where the OTSiG contains a single OTSi cases: the single OTSi case where the OTSiG contains a single OTSi
(see ITU-T draft Recommendation G.807, Figure 10-2) and the multiple (see ITU-T draft Recommendation G.807, Figure 10-2) and the multiple
OTSi case where the OTSiG consists of more than one OTSi (see ITU-T OTSi case where the OTSiG consists of more than one OTSi (see ITU-T
draft Recommendation G.807, Figure 10-3). From a layer 0 topology draft Recommendation G.807, Figure 10-3). From a layer 0 topology
YANG model perspective, the OTSiG is a logical construct that YANG model perspective, the OTSiG is a logical construct that
associates the OTSi's, which belong to the same OTSiG. The typical associates the OTSi's, which belong to the same OTSiG. The typical
application of an OTSiG consisting of more than one OTSi is inverse application of an OTSiG consisting of more than one OTSi is inverse
multiplexing. Constraints exist for the OTSi's belonging to the same multiplexing. Constraints exist for the OTSi's belonging to the same
OTSiG such as: (i) all OTSi's must be co-routed over the same OTSiG such as: (i) all OTSi's must be co-routed over the same optical
optical fibers and nodes and (ii) the differential delay between the fibers and nodes and (ii) the differential delay between the
different OTSi's may not exceed a certain limit. Example: a 400Gbps different OTSi's may not exceed a certain limit. Example: a 400Gbps
client signal may be carried by 4 OTSi's where each OTSi carries client signal may be carried by 4 OTSi's where each OTSi carries
100Gbps of client traffic. 100Gbps of client traffic.
OTSiG OTSiG
_________________________/\__________________________ _________________________/\__________________________
/ \ / \
m=7 m=7
- - - +---------------------------X---------------------------+ - - - - - - +---------------------------X---------------------------+ - - -
/ / / | | / / / / / / | | / / /
/ / /| OTSi OTSi OTSi OTSi |/ / / / / /| OTSi OTSi OTSi OTSi |/ / /
/ / / | ^ ^ ^ ^ | / / / / / / | ^ ^ ^ ^ | / / /
/ / /| | | | | |/ / / / / /| | | | | |/ / /
/ / / | | | | | | / / / / / / | | | | | | / / /
/ / /| | | | | |/ / / / / /| | | | | |/ / /
-4 -3 -2 -1 0 1 2 3 4 5 6 7 8 9 10 11 12 -4 -3 -2 -1 0 1 2 3 4 5 6 7 8 9 10 11 12
--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+--- --+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---
n = ? n = 4
K1 K2 K3 K4 K1 K2 K3 K4
Figure 3: MC Example containing all 4 OTSi signals of an OTSiG
2.3.3. Media Channel (MC)
2.3.3 Media Channel (MC)
The definition of the MC is currently being moved from ITU-T The definition of the MC is currently being moved from ITU-T
Recommendation G.872 [G.872] to the new draft Recommendation G.807 Recommendation G.872 [G.872] to the new draft Recommendation G.807
(still work in progress) [G.807]. Section 3.2.2 defines the term MC (still work in progress) [G.807]. Section 3.2.2 defines the term MC
and section 7.1.2 provides a more detailed description with some and section 7.1.2 provides a more detailed description with some
examples. The definition of the MC is very generic (see ITU-T draft examples. The definition of the MC is very generic (see ITU-T draft
Recommendation G.807, Figure 7-1). In the YANG model below, the MC Recommendation G.807, Figure 7-1). In the YANG model below, the MC
is used with the following semantics: is used with the following semantics:
The MC is an end-to-end topological network construct and can be The MC is an end-to-end topological network construct and can be
considered as an "optical pipe" with a well-defined frequency slot considered as an "optical pipe" with a well-defined frequency slot
between one or more optical transmitters each generating an OTSi and between one or more optical transmitters each generating an OTSi and
the corresponding optical receivers terminating the OTSi's. If the the corresponding optical receivers terminating the OTSi's. If the
MC carries more than one OTSi, it is assumed that these OTSi's MC carries more than one OTSi, it is assumed that these OTSi's belong
belong to the same OTSiG. to the same OTSiG.
m=8 m=8
+-------------------------------X-------------------------------+ +-------------------------------X-------------------------------+
| | | | | |
| +----------X----------+ | +----------X----------+ | | +----------X----------+ | +----------X----------+ |
| | OTSi | | OTSi | | | | OTSi | | OTSi | |
| | ^ | | | ^ | | | | ^ | | | ^ | |
| | | | | | | | | | | | | | | |
-4 -3 -2 -1 0 1 2 3 4 5 6 7 8 9 10 11 12 -4 -3 -2 -1 0 1 2 3 4 5 6 7 8 9 10 11 12
--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+- --+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+-
| n=4 | | n=4 |
K1 K2 K1 K2
<------------------------ Media Channel -----------------------> <------------------------ Media Channel ----------------------->
Figure 4: Figure Caption TBA
The frequency slot of the MC is defined by the n value defining the The frequency slot of the MC is defined by the n value defining the
central frequency of the MC and the m value that defines the width central frequency of the MC and the m value that defines the width of
of the MC following the flexible grid definition in ITU-T the MC following the flexible grid definition in ITU-T Recommendation
Recommendation G.694.1 [G.694.1]. In this model, the effective G.694.1 [G.694.1]. In this model, the effective frequency slot as
frequency slot as defined in ITU-T draft Recommendation G.807 is defined in ITU-T draft Recommendation G.807 is equal to the frequency
equal to the frequency slot of this end-to-end MC. It is also slot of this end-to-end MC. It is also assumed that ROADM devices
assumed that ROADM devices can switch MCs. For various reasons (e.g. can switch MCs. For various reasons (e.g. differential delay), it
differential delay), it is preferred to use a single MC for all is preferred to use a single MC for all OTSi's of the same OTSiG. It
OTSi's of the same OTSiG. It may however not always be possible to may however not always be possible to find a single MC for carrying
find a single MC for carrying all OTSi's of an OTSiG due to spectrum all OTSi's of an OTSiG due to spectrum occupation along the OTSiG
occupation along the OTSiG path. path.
2.3.3. Media Channel Group (MCG) 2.3.4. Media Channel Group (MCG)
The definition of the MCG is currently work in progress in ITU-T and The definition of the MCG is currently work in progress in ITU-T and
is defined in section 7.1.3 of the new ITU-T draft Recommendation is defined in section 7.1.3 of the new ITU-T draft Recommendation
G.807 (still work in progress) [G.807]. The YANG model below assumes G.807 (still work in progress) [G.807]. The YANG model below assumes
that the MCG is a logical grouping of one or more MCs that are used that the MCG is a logical grouping of one or more MCs that are used
to to carry all OTSi's belonging to the same OTSiG. to to carry all OTSi's belonging to the same OTSiG.
The MCG can be considered as an association of MCs without defining The MCG can be considered as an association of MCs without defining a
a hierarchy where each MC is defined by its (n,m) value pair. An MCG hierarchy where each MC is defined by its (n,m) value pair. An MCG
consists of more than one MC when no single MC can be found from consists of more than one MC when no single MC can be found from
source to destination that is wide enough to accommodate all OTSi's source to destination that is wide enough to accommodate all OTSi's
(modulated carriers) that belong to the same OTSiG. In such a case (modulated carriers) that belong to the same OTSiG. In such a case
the set of OTSi's belonging to a single OTSiG have to be split the set of OTSi's belonging to a single OTSiG have to be split across
across 2 or more MCs. 2 or more MCs.
MCG1 = {M1.1, M1.2} MCG1 = {M1.1, M1.2}
__________________________/\__________________________ __________________________/\________________________
/ \ / \
M1.1 M2 M1.2 M1.1 M2 M1.2
____________/\____________ ______/\______ ____/\____ ____________/\____________ _____/\_____ ____/\____
/ \/ \/ \ / \/ \/ \
- - - +---------------------------+-------------+-----------+ - - -
/ / / | | / / / / / / | | / / /
/ / /| OTSi OTSi OTSi |/ / / / / / /| OTSi |/ / /
/ / / | ^ ^ ^ | / / / / / / | ^ | / / /
/ / /| | | | |/ / / / / / /| | |/ / /
/ / / | | | | | / / / / / / | | | / / /
/ / /| | | | |/ / / / / / /| | |/ / /
-7 -4 -1 0 1 2 3 4 5 6 7 8 ... 14 17 20
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
n=0 n=17
K1 K2 K3 K4
- - - +-------------------------------------------------------+ - - - Figure 5: Figure Caption TBA
/ / / | | / / / / / / /| | / / /
/ / /| OTSi OTSi OTSi |/ / / / / / / | OTSi |/ / /
/ / / | ^ ^ ^ | / / / / / / /| ^ | / / /
/ / /| | | | |/ / / / / / / | | |/ / /
/ / / | | | | | / / / / / / /| | | / / /
/ / /| | | | |/ / / / / / / | | |/ / /
-7 -1 0 1 2 3 4 5 6 7 8 9 10 . . . . . 17 . . 21
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--
n=0 n=11 n=17
K1 K2 K3 K4
The MCG is relevant for path computation because all end-to-end MCs The MCG is relevant for path computation because all end-to-end MCs
belonging to the same MCG have to be co-routed, i.e., have to follow belonging to the same MCG have to be co-routed, i.e., have to follow
the same path. Additional constraints may exist (e.g. differential the same path. Additional constraints may exist (e.g. differential
delay). delay).
2.4. Amplifiers 2.4. Amplifiers
Optical amplifiers are in charge of amplifying the optical signal in Optical amplifiers are in charge of amplifying the optical signal in
the optical itself without any electrical conversion. There are the optical itself without any electrical conversion. There are
three main technologies to build amplifiers: Erbium Doped Fiber three main technologies to build amplifiers: Erbium Doped Fiber
Amplifier (EDFA), Raman Fiber Amplifier (RFA), and Semiconductor Amplifier (EDFA), Raman Fiber Amplifier (RFA), and Semiconductor
Optical Amplifier (SOA). Nowadays, most of optical networks uses Optical Amplifier (SOA). Nowadays, most of optical networks uses
EDFAs. However, RFA has an attractive feature that it works in any EDFAs. However, RFA has an attractive feature that it works in any
wavelength band with a similar or lower noise figures compared to wavelength band with a similar or lower noise figures compared to
EDFA. On the other hand, RFAs consumes more power and are more EDFA. On the other hand, RFAs consumes more power and are more
expensive than EDFAs. expensive than EDFAs.
Amplifiers can be classified according to their location in the Amplifiers can be classified according to their location in the
communication link. There are three basic types of amplifiers: ILA, communication link. There are three basic types of amplifiers: ILA,
Pre-Amplifier and Booster. ILA is In-Line Amplifier which is a Pre-Amplifier and Booster. ILA is In-Line Amplifier which is a
separate node type while Pre-Amplifier and Booster Amplifier are separate node type while Pre-Amplifier and Booster Amplifier are
integral elements of ROADM node. From a data modeling perspective, integral elements of ROADM node. From a data modeling perspective,
Pre-Amplifier and Booster Amplifier are internal functions of a Pre-Amplifier and Booster Amplifier are internal functions of a ROADM
ROADM node and as such these elements are hidden within ROADM node. node and as such these elements are hidden within ROADM node. In
In this document, we would avoid internal node details, but attempt this document, we would avoid internal node details, but attempt to
to abstract as much as possible. abstract as much as possible.
One modeling consideration of the ROADM internal is to model power One modeling consideration of the ROADM internal is to model power
parameter through the ROADM, factoring the output power from the parameter through the ROADM, factoring the output power from the Pre-
Pre-Amplifier minus the ROADM power loss would give the input power Amplifier minus the ROADM power loss would give the input power to
to the Booster Amplifier. In other words, Power_in (@ ROADM Booster) the Booster Amplifier. In other words, Power_in (@ ROADM Booster) =
= Power_out (@ ROADM Pre-Amplifier) - Power_loss (@ ROADM Power_out (@ ROADM Pre-Amplifier) - Power_loss (@ ROADM WSS/Filter).
WSS/Filter).
2.5. Transponders 2.5. Transponders
A Transponder is the element that sends and receives the optical A Transponder is the element that sends and receives the optical
signal from a fiber. A transponder is typically characterized by its signal from a fiber. A transponder is typically characterized by its
data rate and the maximum distance the signal can travel. Channel data rate and the maximum distance the signal can travel. Channel
frequency, per channel input power, FEC and Modulation are also frequency, per channel input power, FEC and Modulation are also
associated with a transponder. From a path computation point of associated with a transponder. From a path computation point of
view, the selection of the compatible source and destination view, the selection of the compatible source and destination
transponders is an important factor for optical signal to traverse transponders is an important factor for optical signal to traverse
through the fiber. There are three main approaches to determine through the fiber. There are three main approaches to determine
optical signal compatibility. Application Code based on G.698.2 is optical signal compatibility. Application Code based on G.698.2 is
one approach that only checks the code at both ends of the link. one approach that only checks the code at both ends of the link.
Another approach is organization codes that are specific to an Another approach is organization codes that are specific to an
organization or a vendor. The third approach is specify all the organization or a vendor. The third approach is specify all the
relevant parameters explicitly, e.g., FEC type, Modulation type, relevant parameters explicitly, e.g., FEC type, Modulation type, etc.
etc.
[Editor's Note: The current YANG model described in Section 3 with [Editor's note: The current YANG model described in Section 3 with
respect to the relationship between the transponder attributes and respect to the relationship between the transponder attributes and
the OTSi will need to be investigated in the future revision] the OTSi will need to be investigated in the future revision]
2.6. WSS/Filter 2.6. WSS/Filter
WSS separates the incoming light input spectrally as well as WSS separates the incoming light input spectrally as well as
spatially, then chooses the wavelength that is of interest by spatially, then chooses the wavelength that is of interest by
deflecting it from the original optical path and then couple it to deflecting it from the original optical path and then couple it to
another optical fibre port. WSS/Filter is internal to ROADM. So this another optical fibre port. WSS/Filter is internal to ROADM. So
document does not model the inside of ROADM. this document does not model the inside of ROADM.
2.7. Optical Fiber 2.7. Optical Fiber
There are various optical fiber types defined by ITU-T. There are There are various optical fiber types defined by ITU-T. There are
several fiber-level parameters that need to be factored in, such as, several fiber-level parameters that need to be factored in, such as,
fiber-type, length, loss coefficient, pmd, connectors (in/out). fiber-type, length, loss coefficient, pmd, connectors (in/out).
ITU-T G.652 defines Standard Singlemode Fiber; G.654 Cutoff Shifted ITU-T G.652 defines Standard Singlemode Fiber; G.654 Cutoff Shifted
Fiber; G.655 Non-Zero Dispersion Shifted Fiber; G.656 Non-Zero Fiber; G.655 Non-Zero Dispersion Shifted Fiber; G.656 Non-Zero
Dispersion for Wideband Optical Transport; G.657 Bend-Insensitive Dispersion for Wideband Optical Transport; G.657 Bend-Insensitive
Fiber. There may be other fiber-types that need to be considered. Fiber. There may be other fiber-types that need to be considered.
2.8. ROADM Node Architectures 2.8. ROADM Node Architectures
The ROADM node architectures in today's dense wavelength division The ROADM node architectures in today's dense wavelength division
multiplexing (DWDM) networks can be categorized as follows: multiplexing (DWDM) networks can be categorized as follows:
o Integrated ROADM architecture with integrated optical transponders o Integrated ROADM architecture with integrated optical transponders
o Integrated ROADM architecture with integrated optical transponders
o Integrated ROADM architecture with integrated optical transponders
and single channel add/drop ports for remote optical transponders and single channel add/drop ports for remote optical transponders
o Disaggregated ROADM architecture where the ROADM is subdivided
o Disaggregated ROADM architecture where the ROADM is subdivided
into degree, add/drop, and optical transponder subsystems handled into degree, add/drop, and optical transponder subsystems handled
as separate network elements as separate network elements
The TE topology YANG model augmentations including optical The TE topology YANG model augmentations including optical
impairments for DWDM networks defined below intend to cover all the impairments for DWDM networks defined below intend to cover all the 3
3 categories of ROADM architectures listed above. In the case of a categories of ROADM architectures listed above. In the case of a
disaggregated ROADM architecture, it is assumed that optical domain disaggregated ROADM architecture, it is assumed that optical domain
controller already performs some form of abstraction and presents controller already performs some form of abstraction and presents the
the TE-node representing the disaggregated ROADM in the same way as TE-node representing the disaggregated ROADM in the same way as an
an integrated ROADM with integrated optical transponders if the integrated ROADM with integrated optical transponders if the optical
optical transponder subsystems and the add/drop subsystems are transponder subsystems and the add/drop subsystems are collocated
collocated (short fiber links not imposing significant optical (short fiber links not imposing significant optical impairments).
impairments).
The different ROADM architectures are briefly described and The different ROADM architectures are briefly described and
illustrated in the following subsections. illustrated in the following subsections.
[Editor's Note: The modeling of remote optical transponders located [Editor's note: The modeling of remote optical transponders located
for example in the client device with a single channel link between for example in the client device with a single channel link between
the OT and the add/drop port of the ROADM requires further the OT and the add/drop port of the ROADM requires further
investigations and will be addressed in a future revision of this investigations and will be addressed in a future revision of this
document.] document.]
2.8.1. Integrated ROADM architecture with integrated transponders 2.8.1. Integrated ROADM Architecture with Integrated Optical
Transponders
Figure 2 and Figure <A1> below show the typical architecture of an Figure 2 and Figure 6 below show the typical architecture of an
integrated ROADM node, which contains the optical transponders as an integrated ROADM node, which contains the optical transponders as an
integral part of the ROADM node. Such an integrated ROADM node integral part of the ROADM node. Such an integrated ROADM node
provides DWDM interfaces as external interfaces for interconnecting provides DWDM interfaces as external interfaces for interconnecting
the device with its neighboring ROADMs (see OTS link above). The the device with its neighboring ROADMs (see OTS link above). The
number of these interfaces denote also the degree of the ROADM. A number of these interfaces denote also the degree of the ROADM. A
degree 3 ROADM for example has 3 DWDM links that interconnect the degree 3 ROADM for example has 3 DWDM links that interconnect the
ROADM node with 3 neighboring ROADMs. Additionally, the ROADM ROADM node with 3 neighboring ROADMs. Additionally, the ROADM
provides client interfaces for interconnecting the ROADM with client provides client interfaces for interconnecting the ROADM with client
devices such as IP routers or Ethernet switches. These client devices such as IP routers or Ethernet switches. These client
interfaces are the client interfaces of the integrated optical interfaces are the client interfaces of the integrated optical
transponders. transponders.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
+-----.-------------------------------- .-----+ +-----.-------------------------------- .-----+
| . ROADM . | | . ROADM . |
| . /| +-----------------+ |\ . | | . /| +-----------------+ |\ . |
Line | . / |--| |--| \ . | Line Line | . / |--| |--| \ . | Line
WEST | /| . | |--| |--| | . |\ | EAST WEST | /| . | |--| |--| | . |\ | EAST
------+-/ |-.-| |--| OCX |--| |-.-| \-+----- ------+-/ |-.-| |--| OCX |--| |-.-| \-+-----
skipping to change at page 14, line 27 skipping to change at page 13, line 27
| . +---+ +---+ +---+ +---+ . | | . +---+ +---+ +---+ +---+ . |
| . | O | | O | | O | | O | . | | . | O | | O | | O | | O | . |
| . | T | | T | | T | | T | . | | . | T | | T | | T | | T | . |
| . +---+ +---+ +---+ +---+ . | | . +---+ +---+ +---+ +---+ . |
| . | | | | | | | | . | | . | | | | | | | | . |
+-----.------+-+---+-+---+-+---+-+------.-----+ +-----.------+-+---+-+---+-+---+-+------.-----+
. . . .|.| . |.| . |.| . |.|. . . . . . . .|.| . |.| . |.| . |.|. . . .
| | | | | | | | TE Node | | | | | | | | TE Node
Client Interfaces Client Interfaces
Figure <A1>: ROADM architectiure with integrated transponders Figure 6: ROADM Architectiure with Integrated Transponders
2.8.2. Integrated ROADMs with integrated optical transponders and 2.8.2. Integrated ROADMs with Integrated Optical Transponders and
single channel add/drop interfaces for remote optical transponders Single Channel Add/Drop Interfaces for Remote Optical
Transponders
Figure <A2> below shows the extreme case where all optical Figure 7 below shows the extreme case where all optical transponders
transponders are not integral parts of the ROADM but are separate are not integral parts of the ROADM but are separate devices that are
devices that are interconnected with add/drop ports of the ROADM. If interconnected with add/drop ports of the ROADM. If the optical
the optical transponders and the ROADM are collocated and if short transponders and the ROADM are collocated and if short single channel
single channel fiber links are used to interconnect the optical fiber links are used to interconnect the optical transponders with an
transponders with an add/drop port of the ROADM, the optical domain add/drop port of the ROADM, the optical domain controller may present
controller may present these optical transponders in the same way as these optical transponders in the same way as integrated optical
integrated optical transponders. If, however, the optical transponders. If, however, the optical impairments of the single
impairments of the single channel fiber link between the optical channel fiber link between the optical transponder and the add/drop
transponder and the add/drop port of the ROADM cannot be neglected, port of the ROADM cannot be neglected, it is necessary to represent
it is necessary to represent the fiber link with its optical the fiber link with its optical impairments in the topology model
impairments in the topology model This also implies that the optical This also implies that the optical transponders belong to a separate
transponders belong to a separate TE node [Editor's Note: this TE node
requires further study].
[Editor's note: this requires further study].
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. Abstracted ROADM . . Abstracted ROADM .
+-----.-------------------------------- .-----+ +-----.-------------------------------- .-----+
| . ROADM . | | . ROADM . |
| . /| +-----------------+ |\ . | | . /| +-----------------+ |\ . |
Line | . / |--| |--| \ . | Line Line | . / |--| |--| \ . | Line
WEST | /| . | |--| |--| | . |\ | EAST WEST | /| . | |--| |--| | . |\ | EAST
------+-/ |-.-| |--| OCX |--| |-.-| \-+----- ------+-/ |-.-| |--| OCX |--| |-.-| \-+-----
------+-\ |-.-| |--| |--| |-.-| /-+----- ------+-\ |-.-| |--| |--| |-.-| /-+-----
skipping to change at page 15, line 28 skipping to change at page 14, line 28
Colored OT . +-+ ++ ++ +-+ . Colored OT . +-+ ++ ++ +-+ .
line I/F . | | | | . line I/F . | | | | .
. +---+ +---+ +---+ +---+ . . +---+ +---+ +---+ +---+ .
. | O | | O | | O | | O | . . | O | | O | | O | | O | .
. | T | | T | | T | | T | . . | T | | T | | T | | T | .
. +---+ +---+ +---+ +---+ . . +---+ +---+ +---+ +---+ .
. . . .|.| . |.| . |.| . |.|. . . . . . . .|.| . |.| . |.| . |.|. . . .
| | | | | | | | TE Node | | | | | | | | TE Node
Client Interfaces Client Interfaces
Figure <A2>: ROADM architectiure with remote transponders Figure 7: ROADM Architectiure with Remote Transponders
2.8.3. Disaggregated ROADMs that are subdivided into degree, add/drop, 2.8.3. Disaggregated ROADMs Subdivided into Degree, Add/Drop, and
and optical transponder subsystems Optical Transponder Subsystems
Recently, some DWDM network operators started demanding ROADM Recently, some DWDM network operators started demanding ROADM
subsystems from their vendors. An example is the OpenROADM project subsystems from their vendors. An example is the OpenROADM project
where multiple operators and vendors are developing related YANG where multiple operators and vendors are developing related YANG
models. The subsystems of a disaggregated ROADM are: single degree models. The subsystems of a disaggregated ROADM are: single degree
subsystems, add/drop subsystems and optical transponder subsystems. subsystems, add/drop subsystems and optical transponder subsystems.
These subsystems separate network elements and each network element These subsystems separate network elements and each network element
provides a separate management and control interface. The subsystems provides a separate management and control interface. The subsystems
are typically interconnected using short fiber patch cables and form are typically interconnected using short fiber patch cables and form
together a disaggregated ROADM node. This disaggregated ROADM together a disaggregated ROADM node. This disaggregated ROADM
architecture is depicted in Figure <A3> below. architecture is depicted in Figure 8 below.
As this document defines TE topology YANG model augmentations [TE- As this document defines TE topology YANG model augmentations
TOPO] for the TE topology YANG model provided at the north-bound [I-D.ietf-teas-yang-te-topo] for the TE topology YANG model provided
interface of the optical domain controller, it is a valid assumption at the north-bound interface of the optical domain controller, it is
that the optical domain controller abstracts the subsystems of a a valid assumption that the optical domain controller abstracts the
disaggregated ROADM and presents the disaggregated ROADM in the same subsystems of a disaggregated ROADM and presents the disaggregated
way as an integrated ROADM hiding all the interconnects that are not ROADM in the same way as an integrated ROADM hiding all the
relevant from an external TE topology view. interconnects that are not relevant from an external TE topology
view.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. Abstracted ROADM . . Abstracted ROADM .
+-----.----------+ +----------.-----+ +-----.----------+ +----------.-----+
| Degree 1 | | Degree 2 | | Degree 1 | | Degree 2 |
Line | . +-----+ | + +-----+ . | Line Line | . +-----+ | + +-----+ . | Line
1 | /| . | W |-|------------|-| W | . |\ | 2 1 | /| . | W |-|------------|-| W | . |\ | 2
-----+-/ |-.--| S ******** ******** S |--.-| \-+----- -----+-/ |-.--| S ******** ******** S |--.-| \-+-----
-----+-\ |-.--| S | | * * | | S |--.-| /-+----- -----+-\ |-.--| S | | * * | | S |--.-| /-+-----
| \| . | |-|-+ * * +-|-| | . |/ | | \| . | |-|-+ * * +-|-| | . |/ |
skipping to change at page 16, line 34 skipping to change at page 15, line 32
-----+-\ |-.--| S |-|----*--*----|-| S |--.-| /-+----- -----+-\ |-.--| S |-|----*--*----|-| S |--.-| /-+-----
| \| . | | | * * | | | . |/ | | \| . | | | * * | | | . |/ |
| . +--*--+ | * * | +--*--+ . | | . +--*--+ | * * | +--*--+ . |
+-----.-----*----+ * * +----*-----.-----+ +-----.-----*----+ * * +----*-----.-----+
. * * * * . . * * * * .
. +--*---------*--*---------*--+ . . +--*---------*--*---------*--+ .
. | ADD | . . | ADD | .
. | DROP | . . | DROP | .
. +----------------------------+ . . +----------------------------+ .
Colored OT . | | | | . Colored OT . | | | | .
line I/F . +---+ +---+ +---+ +---+ . Line I/F . +---+ +---+ +---+ +---+ .
. | O | | O | | O | | O | . . | O | | O | | O | | O | .
. | T | | T | | T | | T | . . | T | | T | | T | | T | .
. +---+ +---+ +---+ +---+ . . +---+ +---+ +---+ +---+ .
. . .|.| . |.| . |.| . |.|. . . . . .|.| . |.| . |.| . |.|. . .
| | | | | | | | TE Node | | | | | | | | TE Node
Client Interfaces Client Interfaces
Figure <A3>: ROADM architectiure with remote transponders Figure 8: Disaggregated ROADM Architecture with Remote Transponders
3. YANG Model (Tree Structure) 2.8.4. Optical Impairments Imposed by ROADM Nodes
module: ietf-optical-impairment-topology When an optical OTSi signal traverses a ROADM node, optical
augment /nw:networks/nw:network/nw:network-types/tet:te-topology: impairments are imposed on the signal by various passive or active
+--rw optical-impairment-topology! optical components inside the ROADM node. Examples of optical
augment /nw:networks/nw:network/nt:link/tet:te/tet:te-link-attributes: impairments are:
+--ro OMS-attributes
+--ro generalized-snr? decimal64
+--ro equalization-mode identityref
+--ro (power-param)?
| +--:(channel-power)
| | +--ro nominal-channel-power? decimal64
| +--:(power-spectral-density)
| +--ro nominal-power-spectral-density? decimal64
+--ro media-channel-group* [i]
| +--ro i int16
| +--ro media-channels* [flexi-n]
| +--ro flexi-n uint16
| +--ro flexi-m? uint16
| +--ro OTSiG-ref? leafref
| +--ro OTSi-ref? leafref
+--ro OMS-elements* [elt-index]
+--ro elt-index uint16
+--ro uid? string
+--ro type identityref
+--ro element
+--ro (element)?
+--:(amplifier)
| +--ro amplifier
| +--ro type_variety string
| +--ro operational
| +--ro actual-gain
| | decimal64
| +--ro tilt-target
| | decimal64
| +--ro out-voa
| | decimal64
| +--ro in-voa
| | decimal64
| +--ro (power-param)?
| +--:(channel-power)
| | +--ro nominal-channel-power?
| | decimal64
| +--:(power-spectral-density)
| +--ro nominal-power-spectral-density?
| decimal64
+--:(fiber)
| +--ro fiber
| +--ro type_variety string
| +--ro length decimal64
| +--ro loss_coef decimal64
| +--ro total_loss decimal64
| +--ro pmd? decimal64
| +--ro conn_in? decimal64
| +--ro conn_out? decimal64
+--:(concentratedloss)
+--ro concentratedloss
+--ro loss? decimal64
augment /nw:networks/nw:network/nw:node/tet:te
/tet:tunnel-termination-point:
+--ro OTSiG-element* [OTSiG-identifier]
| +--ro OTSiG-identifier int16
| +--ro OTSiG-container
| +--ro OTSi* [OTSi-carrier-id]
| +--ro OTSi-carrier-id int16
| +--ro OTSi-carrier-frequency? decimal64
| +--ro OTSi-signal-width? decimal64
| +--ro channel-delta-power? decimal64
+--ro transponders-list* [transponder-id]
+--ro transponder-id uint32
+--ro (mode)?
| +--:(G.692.2)
| | +--ro standard_mode? layer0-types:standard-mode
| +--:(organizational_mode)
| | +--ro operational-mode?
| | | layer0-types:operational-mode
| | +--ro organization-identifier?
| | layer0-types:vendor-identifier
| +--:(explicit_mode)
| +--ro available-modulation* identityref
| +--ro modulation-type? identityref
| +--ro available-baud-rates* uint32
| +--ro configured-baud-rate? uint32
| +--ro available-FEC* identityref
| +--ro FEC-type? identityref
| +--ro FEC-code-rate? decimal64
| +--ro FEC-threshold? decimal64
+--ro power? int32
+--ro power-min? int32
+--ro power-max? int32
augment /nw:networks/nw:network/nw:node/tet:te
/tet:tunnel-termination-point:
+--ro transponder-list* [carrier-id]
+--ro carrier-id uint32
4. Optical Impairment Topology YANG Model o Chromatic dispersion (CD)
o Polarization mode dispersion (PMD)
o Polarization dependent loss (PDL)
o Optical amplifier noise due to amplified spontaneous emission
(ASE)
o In-band cross-talk
o Filtering effects (for further study)
<CODE BEGINS> file ietf-optical-impairment-topology@2018-05-22.yang A ROADM node contains a wavelength selective photonic switching
module ietf-optical-impairment-topology { function (WSS)that is capable of switching media channels (MCs)
yang-version 1.1; described in Section 2.3.4. These MCs can be established between two
line ports of the ROADM or between a line port and an Add/Drop port
of the ROADM. The Add/Drop ports of a ROADM are those ports to which
optical transponders are connected. Typically, this is a single
channel signal (single OTSi), but principally this could also be a
group of OTSi signals. The optical impairments associated with these
MCs are different and the paths of the MCs inside the ROADM node can
be categorized as follows:
namespace "urn:ietf:params:xml:ns:yang:ietf-optical-impairment-topology"; o Express path: MC path between two line ports of the ROADM
(unidirectional)
prefix "optical-imp-topo"; o Add Path: MC path from an Add port to a line port of the ROADM
import ietf-network { o Drop path: MC path from a line port to a Drop port of the ROADM
prefix "nw";
}
import ietf-network-topology { Due to the symmetrical architecture of the ROADM node, the optical
prefix "nt"; impairments associated with the express path are typically the same
} between any two line ports of the ROADM whereas the optical
impairments for the add and drop paths are different and therefore
have to be modeled separately.
import ietf-te-topology { The optical impairments associated with each of the three types of
prefix "tet"; ROADM-node-internal paths described above are modeled as optical
} impairment parameter sets. These parameter sets are modeled as an
augmentation of the te-node-attributes defined in
[I-D.ietf-teas-yang-te-topo]. The te-node-attributes are augmented
with a list of roadm-path-impairments for the three ROADM path types
distinguished by the impairment-type. Each roadm-path-impairments
list entry contains the set of optical impairment parameters for one
of the three path types indicated by the impairment-type. For the
optical feasibility calculation based on the optical impairments, it
is necessary to know whether the optical power of the OTSi stays
within a certain power window. This is reflected by some optical
power related parameters such as loss parameters or power parameters,
which are included in the optical impairment parameter sets (see tree
view in Section 3).
import ietf-layer0-types { [I-D.ietf-teas-yang-te-topo] defines a connectivity matrix and a
prefix "layer0-types"; local link connectivity list for the TE node. The connectivity
} matrix describes the connectivity for the express paths between the
different lines of the ROADM and the local link connectivity list
describes the connectivity for the Add and Drop paths of the ROADM.
These matrices are augmented with a new roadm-path-impairment matrix
element, an add-path-impairment, and drop-path-impairment matrix
element, respectively, which are defined as a pointer to the
corresponding entry in the roadm-path-impairments list (leaf-ref).
organization [Editor's note: this section is still work in progress]
"IETF CCAMP Working Group";
contact 3. YANG Model (Tree Structure)
"Editor: Young Lee <younglee.tx@gmail.com>
Editor: Haomian Zheng <zhenghaomian@huawei.com>
Editor: Nicola Sambo <nicosambo@gmail.com>
Editor: Victor Lopez <victor.lopezalvarez@telefonica.com>
Editor: Gabriele Galimberti <ggalimbe@cisco.com>
Editor: Giovanni Martinelli <giomarti@cisco.com>
Editor: Auge Jean-Luc <jeanluc.auge@orange.com>
Editor: Le Rouzic Esther <esther.lerouzic@orange.com>
Editor: Julien Meuric <julien.meuric@orange.com>
Editor: Italo Busi <Italo.Busi@huawei.com>
Editor: Dieter Beller <dieter.beller@nokia.com>
Editor: Sergio Belotti <Sergio.belotti@nokia.com>
Editor: Griseri Enrico <enrico.griseri@nokia.com>
Editor: Gert Grammel <ggrammel@juniper.net>";
description module: ietf-optical-impairment-topology
"This module contains a collection of YANG definitions for augment /nw:networks/nw:network/nw:network-types/tet:te-topology:
impairment-aware optical networks. +--rw optical-impairment-topology!
augment /nw:networks/nw:network/nt:link/tet:te/
tet:te-link-attributes:
+--ro OMS-attributes
+--ro generalized-snr? decimal64
+--ro equalization-mode identityref
+--ro (power-param)?
| +--:(channel-power)
| | +--ro nominal-channel-power? decimal64
| +--:(power-spectral-density)
| +--ro nominal-power-spectral-density? decimal64
+--ro media-channel-group* [i]
| +--ro i int16
| +--ro media-channels* [flexi-n]
| +--ro flexi-n uint16
| +--ro flexi-m? uint16
| +--ro OTSiG-ref? -> /nw:networks/network/node/tet:te/
tunnel-termination-point/OTSiG-element/OTSiG-identifier
| +--ro OTSi-ref? -> /nw:networks/network/node/tet:te/
tunnel-termination-point/
OTSiG-element[OTSiG-identifier=current()/../OTSiG-ref]/
OTSiG-container/OTSi/OTSi-carrier-id
+--ro OMS-elements* [elt-index]
+--ro elt-index uint16
+--ro uid? string
+--ro type identityref
+--ro element
+--ro (element)?
+--:(amplifier)
| +--ro amplifier
| +--ro type-variety string
| +--ro operational
| +--ro actual-gain decimal64
| +--ro tilt-target decimal64
| +--ro out-voa decimal64
| +--ro in-voa decimal64
| +--ro (power-param)?
| +--:(channel-power)
| | +--ro nominal-channel-power?
decimal64
| +--:(power-spectral-density)
| +--ro nominal-power-spectral-density?
decimal64
+--:(fiber)
| +--ro fiber
| +--ro type-variety string
| +--ro length decimal64
| +--ro loss-coef decimal64
| +--ro total-loss decimal64
| +--ro pmd? decimal64
| +--ro conn-in? decimal64
| +--ro conn-out? decimal64
+--:(concentratedloss)
+--ro concentratedloss
+--ro loss? decimal64
augment /nw:networks/nw:network/nw:node/tet:te/
tet:tunnel-termination-point:
+--ro OTSiG-element* [OTSiG-identifier]
| +--ro OTSiG-identifier int16
| +--ro OTSiG-container
| +--ro OTSi* [OTSi-carrier-id]
| +--ro OTSi-carrier-id int16
| +--ro OTSi-carrier-frequency? decimal64
| +--ro OTSi-signal-width? decimal64
| +--ro channel-delta-power? decimal64
+--ro transponders-list* [transponder-id]
+--ro transponder-id uint32
+--ro (mode)?
| +--:(G.692.2)
| | +--ro standard-mode? standard-mode
| +--:(organizational-mode)
| | +--ro operational-mode? operational-mode
| | +--ro organization-identifier? vendor-identifier
| +--:(explicit-mode)
| +--ro available-modulation-types* identityref
| +--ro configured-modulation-type? identityref
| +--ro available-baud-rates* uint32
| +--ro configured-baud-rate? uint32
| +--ro available-FEC-types* identityref
| +--ro configured-FEC-type? identityref
| +--ro FEC-code-rate? decimal64
| +--ro FEC-threshold? decimal64
+--ro power? int32
+--ro power-min? int32
+--ro power-max? int32
augment /nw:networks/nw:network/nw:node/tet:te/
tet:tunnel-termination-point:
+--ro transponder-list* [carrier-id]
+--ro carrier-id uint32
augment /nw:networks/nw:network/nw:node/tet:te/
tet:te-node-attributes:
+--ro roadm-path-impairments* [roadm-path-impairments-id]
+--ro roadm-path-impairments-id uint32
+--ro (impairment-type)?
+--:(roadm-express-path)
| +--ro roadm-express-path
| +--ro roadm-pmd? decimal64
| +--ro roadm-cd? decimal64
| +--ro roadm-pdl? decimal64
| +--ro roadm-inband-crosstalk? decimal64
| +--ro roadm-maxloss? decimal64
+--:(roadm-add-path)
| +--ro roadm-add-path
| +--ro roadm-pmd? decimal64
| +--ro roadm-cd? decimal64
| +--ro roadm-pdl? decimal64
| +--ro roadm-inband-crosstalk? decimal64
| +--ro roadm-maxloss? decimal64
| +--ro roadm-pmax? decimal64
| +--ro roadm-osnr? decimal64
| +--ro roadm-noise-figure? decimal64
+--:(roadm-drop-path)
+--ro roadm-drop-path
+--ro roadm-pmd? decimal64
+--ro roadm-cd? decimal64
+--ro roadm-pdl? decimal64
+--ro roadm-inband-crosstalk? decimal64
+--ro roadm-maxloss? decimal64
+--ro roadm-minloss? decimal64
+--ro roadm-typloss? decimal64
+--ro roadm-pmin? decimal64
+--ro roadm-pmax? decimal64
+--ro roadm-ptyp? decimal64
+--ro roadm-osnr? decimal64
+--ro roadm-noise-figure? decimal64
augment /nw:networks/nw:network/nw:node/tet:te/
tet:information-source-entry/tet:connectivity-matrices:
+--ro roadm-path-impairments? -> ../../../
tet:te-node-attributes/roadm-path-impairments/
roadm-path-impairments-id
augment /nw:networks/nw:network/nw:node/tet:te/
tet:information-source-entry/tet:connectivity-matrices/
tet:connectivity-matrix:
+--ro roadm-path-impairments? -> ../../../../
tet:te-node-attributes/roadm-path-impairments/
roadm-path-impairments-id
augment /nw:networks/nw:network/nw:node/tet:te/
tet:te-node-attributes/tet:connectivity-matrices:
+--ro roadm-path-impairments? -> ../../roadm-path-impairments/
roadm-path-impairments-id
augment /nw:networks/nw:network/nw:node/tet:te/
tet:te-node-attributes/tet:connectivity-matrices/
tet:connectivity-matrix:
+--ro roadm-path-impairments? -> ../../../
roadm-path-impairments/roadm-path-impairments-id
augment /nw:networks/nw:network/nw:node/tet:te/
tet:tunnel-termination-point/tet:local-link-connectivities:
+--ro add-path-impairments? -> ../../../
tet:te-node-attributes/roadm-path-impairments/
roadm-path-impairments-id
+--ro drop-path-impairments? -> ../../../
tet:te-node-attributes/roadm-path-impairments/
roadm-path-impairments-id
augment /nw:networks/nw:network/nw:node/tet:te/
tet:tunnel-termination-point/tet:local-link-connectivities/
tet:local-link-connectivity:
+--ro add-path-impairments? -> ../../../../
tet:te-node-attributes/roadm-path-impairments/
roadm-path-impairments-id
+--ro drop-path-impairments? -> ../../../../
tet:te-node-attributes/roadm-path-impairments/
roadm-path-impairments-id
Copyright (c) 2019 IETF Trust and the persons identified as 4. Optical Impairment Topology YANG Model
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or [Editor's note: YANG code below may have to be updated before
without modification, is permitted pursuant to, and subject submission!]
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
(http://trustee.ietf.org/license-info).";
revision 2019-05-22 { <CODE BEGINS>
description module ietf-optical-impairment-topology {
"Initial Version"; yang-version 1.1;
reference
"RFC XXXX: A Yang Data Model for Impairment-aware
Optical Networks";
}
identity modulation { namespace "urn:ietf:params:xml"
description "base identity for modulation type"; +":ns:yang:ietf-optical-impairment-topology";
}
identity QPSK { prefix "optical-imp-topo";
base modulation;
description
"QPSK (Quadrature Phase Shift Keying) modulation";
}
identity DP_QPSK { import ietf-network {
base modulation; prefix "nw";
description
"DP-QPSK (Dual Polarization Quadrature
Phase Shift Keying) modulation";
}
identity QAM8 {
base modulation;
description
"8QAM (8-State Quadrature Amplitude Modulation) modulation";
}
identity QAM16 {
base modulation;
description
"QAM16 (Quadrature Amplitude Modulation)";
}
identity DP_QAM8 {
base modulation;
description
"DP-QAM8 (Dual Polarization Quadrature Amplitude Modulation)";
}
identity DC_DP_QAM8 {
base modulation;
description
"DC DP-QAM8 (Dual Polarization Quadrature Amplitude Modulation)";
}
identity DP_QAM16 {
base modulation;
description
"DP-QAM16 (Dual Polarization Quadrature Amplitude Modulation)";
}
identity DC_DP_QAM16 {
base modulation;
description
"DC DP-QAM16 (Dual Polarization Quadrature Amplitude Modulation)";
}
identity FEC { }
description
"Enumeration that defines the type of
Forward Error Correction";
}
identity reed-solomon {
base FEC;
description
"Reed-Solomon error correction";
}
identity hamming-code {
base FEC;
description
"Hamming Code error correction";
}
identity golay {
base FEC;
description "Golay error correction";
}
typedef fiber-type { import ietf-network-topology {
type enumeration { prefix "nt";
enum G.652 { }
description "G.652 Standard Singlemode Fiber";
}
enum G.654 {
description "G.654 Cutoff Shifted Fiber";
}
enum G.653 {
description "G.653 Dispersion Shifted Fiber";
}
enum G.655 {
description "G.655 Non-Zero Dispersion Shifted Fiber";
}
enum G.656 {
description "G.656 Non-Zero Dispersion for Wideband
Optical Transport";
}
enum G.657 {
description "G.657 Bend-Insensitive Fiber";
}
}
description
"ITU-T based fiber-types";
}
grouping transponder-attributes { import ietf-te-topology {
description "Configuration of an optical transponder"; prefix "tet";
}
leaf-list available-modulation { import ietf-layer0-types {
type identityref { prefix "layer0-types";
base modulation; }
}
config false;
description
"List determining all the available modulations";
}
leaf modulation-type { organization
type identityref { "IETF CCAMP Working Group";
base modulation;
}
config false;
description
"Modulation configured for the transponder";
}
leaf-list available-baud-rates { contact
type uint32; "Editor: Young Lee <younglee.tx@gmail.com>
units Bd; Editor: Haomian Zheng <zhenghaomian@huawei.com>
config false; Editor: Nicola Sambo <nicosambo@gmail.com>
description Editor: Victor Lopez <victor.lopezalvarez@telefonica.com>
"list of available baud-rates. Baud-rate is the unit for Editor: Gabriele Galimberti <ggalimbe@cisco.com>
symbol rate or modulation rate in symbols per second or Editor: Giovanni Martinelli <giomarti@cisco.com>
pulses per second. It is the number of distinct symbol Editor: Jean-Luc Auge <jeanluc.auge@orange.com>
changes (signaling events) made to the transmission medium Editor: Le Rouzic Esther <esther.lerouzic@orange.com>
per second in a digitally modulated signal or a line code"; Editor: Julien Meuric <julien.meuric@orange.com>
Editor: Italo Busi <Italo.Busi@huawei.com>
Editor: Dieter Beller <dieter.beller@nokia.com>
Editor: Sergio Belotti <Sergio.belotti@nokia.com>
Editor: Griseri Enrico <enrico.griseri@nokia.com>
Editor: Gert Grammel <ggrammel@juniper.net>";
} description
"This module contains a collection of YANG definitions for
impairment-aware optical networks.
leaf configured-baud-rate { Copyright (c) 2019 IETF Trust and the persons identified as
type uint32; authors of the code. All rights reserved.
units Bd;
config false;
description "configured baud-rate";
}
leaf-list available-FEC { Redistribution and use in source and binary forms, with or
type identityref { without modification, is permitted pursuant to, and subject
base FEC; to the license terms contained in, the Simplified BSD
} License set forth in Section 4.c of the IETF Trust's Legal
config false; Provisions Relating to IETF Documents
description "List determining all the available FEC"; (http://trustee.ietf.org/license-info).";
}
leaf FEC-type { revision 2020-03-09 {
type identityref { description
base FEC; "Initial Version";
} reference
config false; "RFC XXXX: A Yang Data Model for Impairment-aware
description Optical Networks";
"FEC type configured for the transponder"; }
}
leaf FEC-code-rate { // identity
type decimal64 {
fraction-digits 8;
range "0..max";
}
config false;
description "FEC-code-rate";
}
leaf FEC-threshold { identity modulation {
type decimal64 { description "base identity for modulation type";
fraction-digits 8; }
range "0..max";
}
config false;
description
"Threshold on the BER, for which FEC is able to correct errors";
}
} identity QPSK {
base modulation;
description
"QPSK (Quadrature Phase Shift Keying) modulation";
}
grouping sliceable-transponder-attributes { identity DP-QPSK {
description base modulation;
"Configuration of a sliceable transponder."; description
list transponder-list { "DP-QPSK (Dual Polarization Quadrature
key "carrier-id"; Phase Shift Keying) modulation";
config false; }
description "List of carriers"; identity QAM8 {
leaf carrier-id { base modulation;
type uint32; description
config false; "8QAM (8-State Quadrature Amplitude Modulation) modulation";
description "Identifier of the carrier"; }
} identity QAM16 {
} base modulation;
} description
"QAM16 (Quadrature Amplitude Modulation)";
}
identity DP-QAM8 {
base modulation;
description
"DP-QAM8 (Dual Polarization Quadrature Amplitude Modulation)";
}
identity DC-DP-QAM8 {
base modulation;
description
"DC DP-QAM8 (Dual Polarization Quadrature Amplitude Modulation)";
}
identity DP-QAM16 {
base modulation;
description
"DP-QAM16 (Dual Polarization Quadrature Amplitude Modulation)";
}
identity DC-DP-QAM16 {
base modulation;
description
"DC DP-QAM16 (Dual Polarization Quadrature
Amplitude Modulation)";
}
grouping optical-fiber-data { identity FEC {
description description
"optical link (fiber) attributes with impairment data"; "Enumeration that defines the type of
leaf fiber-type { Forward Error Correction";
type fiber-type; }
config false; identity reed-solomon {
description "fiber-type"; base FEC;
} description
"Reed-Solomon error correction";
}
identity hamming-code {
base FEC;
description
"Hamming Code error correction";
}
identity golay {
base FEC;
description "Golay error correction";
}
leaf span-length { // typedef
type decimal64 {
fraction-digits 2;
}
units "km";
config false;
description "the lenght of the fiber span in km";
}
leaf input-power { typedef fiber-type {
type decimal64 { type enumeration {
fraction-digits 2; enum G.652 {
} description "G.652 Standard Singlemode Fiber";
units "dBm"; }
config false; enum G.654 {
description description "G.654 Cutoff Shifted Fiber";
"Average input power level estimated at the receiver }
of the link"; enum G.653 {
} description "G.653 Dispersion Shifted Fiber";
}
enum G.655 {
description "G.655 Non-Zero Dispersion Shifted Fiber";
}
enum G.656 {
description "G.656 Non-Zero Dispersion for Wideband
Optical Transport";
leaf output-power { }
type decimal64 { enum G.657 {
fraction-digits 2; description "G.657 Bend-Insensitive Fiber";
} }
units "dBm"; }
description description
"Mean launched power at the transmitter of the link"; "ITU-T based fiber-types";
}
} /*temporary defined here for disalignment with*/
/* ietf-layer0-types module*/
leaf pmd { typedef operational-mode {
type decimal64 { type string;
fraction-digits 8; description
range "0..max"; "Vendor-specific mode that guarantees
} interoperability.";
units "ps/(km)^0.5"; reference "ITU-T G.698.2 (11/2018)";
config false; }
description
"Polarization Mode Dispersion";
}
leaf cd { // temporary defined here for disalignment with
type decimal64 { //ietf-layer0-types module
fraction-digits 5; typedef standard-mode {
} type string;
units "ps/nm/km"; description
config false; "ITU-T G.698.2 standard mode that guarantees
description interoperability.
"Cromatic Dispersion"; It must be an string with the following format:
} B-DScW-ytz(v) where all these attributes
are conformant
to the ITU-T recomendation";
reference "ITU-T G.698.2 (11/2018)";
}
leaf osnr { // temporary defined here for disalignment
type decimal64 { //with ietf-layer0-types module
fraction-digits 5; typedef vendor-identifier {
} type string;
units "dB"; description
config false; "vendor identifier that uses vendor-specific mode";
description reference
"Optical Signal-to-Noise Ratio (OSNR) estimated "RFC7581: Routing and Wavelength Assignment Information
at the receiver"; Encoding for Wavelength Switched Optical Networks";
} }
leaf sigma { // grouping
type decimal64 {
fraction-digits 5;
}
units "dB";
config false;
description
"sigma in the Gausian Noise Model";
}
}
grouping optical-channel-data { grouping transponder-attributes {
description description "Configuration of an optical transponder";
"optical impairment data per channel/wavelength";
leaf bit-rate {
type decimal64 {
fraction-digits 8;
range "0..max";
}
units "Gbit/s";
config false;
description
"Gross bit rate";
}
leaf BER { leaf-list available-modulation-types {
type decimal64 { type identityref {
fraction-digits 18; base modulation;
range "0..max"; }
} config false;
config false; description
description "List of modulation types the OTSi supports";
"BER (Bit Error Rate)"; }
}
leaf ch-input-power { leaf configured-modulation-type {
type decimal64 { type identityref {
fraction-digits 2; base modulation;
} }
units "dBm"; config false;
config false; description
description "Currently configured OTSi modulation type";
"Per channel average input power level }
estimated at the receiver of the link";
}
leaf ch-pmd { leaf-list available-baud-rates {
type decimal64 { type uint32;
fraction-digits 8; units Bd;
range "0..max"; config false;
} description
units "ps/(km)^0.5"; "list of available baud-rates.
config false; Baud-rate is the unit for
description symbol rate or modulation rate
"per channel Polarization Mode Dispersion"; in symbols per second or
} pulses per second.
It is the number of distinct symbol
changes (signal events) made to the
transmission medium
per second in a digitally
modulated signal or a line code";
}
leaf ch-cd { leaf configured-baud-rate {
type decimal64 { type uint32;
fraction-digits 5; units Bd;
} config false;
units "ps/nm/km"; description "configured baud-rate";
config false; }
description
"per channel Cromatic Dispersion"; leaf-list available-FEC-types {
} type identityref {
base FEC;
}
config false;
description "List determining all the available FEC";
}
leaf ch-osnr { leaf configured-FEC-type {
type decimal64 { type identityref {
fraction-digits 5; base FEC;
} }
units "dB"; config false;
config false; description
description "FEC type configured for the transponder";
"per channel Optical Signal-to-Noise Ratio }
(OSNR) estimated at the receiver";
}
leaf q-factor { leaf FEC-code-rate {
type decimal64 { type decimal64 {
fraction-digits 5; fraction-digits 8;
} range "0..max";
units "dB"; }
config false; config false;
description description "FEC-code-rate";
"q-factor estimated at the receiver"; }
}
}
grouping standard_mode { leaf FEC-threshold {
description type decimal64 {
"ITU-T G.698.2 standard mode that guarantees interoperability. fraction-digits 8;
It must be an string with the following format: range "0..max";
B-DScW-ytz(v) where all these attributes are conformant }
to the ITU-T recomendation"; config false;
description
"Threshold on the BER, for which FEC
is able to correct errors";
}
leaf standard_mode { }
type layer0-types:standard-mode;
config false;
description
"G.698.2 standard mode";
}
}
grouping organizational_mode { grouping sliceable-transponder-attributes {
description description
"Transponder operational mode supported by organizations or "Configuration of a sliceable transponder.";
vendor"; list transponder-list {
key "carrier-id";
config false;
description "List of carriers";
leaf carrier-id {
type uint32;
config false;
description "Identifier of the carrier";
}
}
leaf operational-mode { }
type layer0-types:operational-mode;
config false;
description
"configured organization- or vendor-specific
application identifiers (AI) supported by the transponder";
}
leaf organization-identifier { grouping optical-fiber-data {
type layer0-types:vendor-identifier; description
config false; "optical link (fiber) attributes with impairment data";
description leaf fiber-type {
"organization identifier that uses organizational type fiber-type;
mode"; config false;
description "fiber-type";
}
} leaf span-length {
} type decimal64 {
fraction-digits 2;
}
units "km";
config false;
description "the lenght of the fiber span in km";
}
/* leaf input-power {
* Identities type decimal64 {
*/ fraction-digits 2;
identity type-element { }
description units "dBm";
"Base identity for element type"; config false;
} description
"Average input power level estimated at the receiver
of the link";
}
identity Fiber { leaf output-power {
base type-element; type decimal64 {
description fraction-digits 2;
"Fiber element"; }
} units "dBm";
description
"Mean launched power at the transmitter of the link";
}
identity Roadm { leaf pmd {
base type-element; type decimal64 {
description fraction-digits 8;
"Roadm element"; range "0..max";
} }
units "ps/(km)^0.5";
config false;
description
"Polarization Mode Dispersion";
}
identity Edfa { leaf cd {
base type-element; type decimal64 {
description fraction-digits 5;
"Edfa element"; }
} units "ps/nm/km";
config false;
description
"Cromatic Dispersion";
}
identity Concentratedloss { leaf osnr {
base type-element; type decimal64 {
description fraction-digits 5;
"Concentratedloss element"; }
} units "dB";
config false;
description
"Optical Signal-to-Noise Ratio (OSNR) estimated
at the receiver";
}
identity type-power-mode { leaf sigma {
description type decimal64 {
"power equalization mode used within the OMS and its elements"; fraction-digits 5;
}
units "dB";
config false;
description
"sigma in the Gausian Noise Model";
}
}
} grouping optical-channel-data {
description
"optical impairment data per channel/wavelength";
leaf bit-rate {
type decimal64 {
fraction-digits 8;
range "0..max";
}
units "Gbit/s";
config false;
description
"Gross bit rate";
}
leaf BER {
type decimal64 {
fraction-digits 18;
range "0..max";
}
config false;
description
"BER (Bit Error Rate)";
}
identity power-spectral-density { leaf ch-input-power {
base type-power-mode; type decimal64 {
description fraction-digits 2;
"all elements must use power spectral density (W/Hz)"; }
} units "dBm";
config false;
description
"Per channel average input power level
estimated at the receiver of the link";
}
identity channel-power { leaf ch-pmd {
base type-power-mode; type decimal64 {
description fraction-digits 8;
"all elements must use power (dBm)"; range "0..max";
} }
units "ps/(km)^0.5";
config false;
description
"per channel Polarization Mode Dispersion";
}
/* leaf ch-cd {
* Groupings type decimal64 {
*/ fraction-digits 5;
grouping amplifier-params { }
description "describes parameters for an amplifier"; units "ps/nm/km";
container amplifier{ config false;
description "amplifier type, operatonal parameters are described"; description
leaf type_variety { "per channel Cromatic Dispersion";
type string ; }
mandatory true ;
description
"String identifier of amplifier type referencing
a specification in a separate equipment catalog";
}
container operational {
description "amplifier operationnal parameters";
leaf actual-gain {
type decimal64 {
fraction-digits 2;
}
units dB ;
mandatory true ;
description "..";
}
leaf tilt-target {
type decimal64 {
fraction-digits 2;
}
mandatory true ;
description "..";
}
leaf out-voa {
type decimal64 {
fraction-digits 2;
}
units dB;
mandatory true;
description "..";
}
leaf in-voa {
type decimal64 {
fraction-digits 2;
}
units dB;
mandatory true;
description "..";
}
uses power-param;
}
}
}
grouping fiber-params { leaf ch-osnr {
description "String identifier of fiber type referencing a specification in a type decimal64 {
separate equipment catalog"; fraction-digits 5;
container fiber { }
description "fiber characteristics"; units "dB";
leaf type_variety { config false;
type string ; description
mandatory true ; "per channel Optical Signal-to-Noise Ratio
description "fiber type"; (OSNR) estimated at the receiver";
}
leaf length {
type decimal64 {
fraction-digits 2;
}
units km;
mandatory true ;
description "length of fiber";
}
leaf loss_coef {
type decimal64 {
fraction-digits 2;
}
units dB/km;
mandatory true ;
description "loss coefficient of the fiber";
}
leaf total_loss {
type decimal64 {
fraction-digits 2;
}
units dB;
mandatory true ;
description
"includes all losses: fiber loss and conn_in and conn_out losses";
}
leaf pmd{
type decimal64 {
fraction-digits 2;
}
units sqrt(ps);
description "pmd of the fiber";
}
leaf conn_in{
type decimal64 {
fraction-digits 2;
}
units dB;
description "connector-in";
}
leaf conn_out{
type decimal64 {
fraction-digits 2;
}
units dB;
description "connector-out";
} }
}
}
grouping roadm-params{ leaf q-factor {
description "roadm parameters description"; type decimal64 {
container roadm{ fraction-digits 5;
description "roadm parameters"; }
leaf type_variety { units "dB";
type string ; config false;
mandatory true ; description
description "String identifier of roadm type referencing a specification in a "q-factor estimated at the receiver";
separate equipment catalog"; }
} }
leaf loss {
type decimal64 {
fraction-digits 2;
}
units dB ;
description "..";
}
}
}
grouping concentratedloss-params{ grouping standard-mode {
description "concentrated loss"; description
container concentratedloss{ "ITU-T G.698.2 standard mode that guarantees interoperability.
description "concentrated loss"; It must be an string with the following format:
leaf loss { B-DScW-ytz(v) where all these attributes are conformant
type decimal64 { to the ITU-T recomendation";
fraction-digits 2;
}
units dB ;
description "..";
}
}
}
grouping power-param{ leaf standard-mode {
description type standard-mode;
"optical power or PSD after the ROADM or after the out-voa"; config false;
choice power-param { description
description "G.698.2 standard mode";
"select the mode: channel power or power spectral density"; }
case channel-power { }
/* when "equalization-mode='channel-power'"; */
leaf nominal-channel-power{
type decimal64 {
fraction-digits 1;
}
units dBm ;
description
" Reference channel power after the ROADM or after the out-voa. ";
}
}
case power-spectral-density{
/* when "equalization-mode='power-spectral-density'"; */
leaf nominal-power-spectral-density{
type decimal64 {
fraction-digits 16;
}
units W/Hz ;
description
" Reference power spectral density after the ROADM or after the out-voa.
Typical value : 3.9 E-14, resolution 0.1nW/MHz";
}
}
}
}
grouping oms-general-optical-params { grouping organizational-mode {
description "OMS link optical parameters"; description
leaf generalized-snr { "Transponder operational mode supported by organizations or
type decimal64 { vendor";
fraction-digits 5;
} leaf operational-mode {
units "dB@0.1nm"; type operational-mode;
description "generalized snr"; config false;
} description
leaf equalization-mode{ "configured organization- or vendor-specific
type identityref { application identifiers (AI) supported by the transponder";
base type-power-mode; }
}
mandatory true;
description "equalization mode";
}
uses power-param;
}
grouping OTSiG { leaf organization-identifier {
description "OTSiG definition , representing client digital information stream type vendor-identifier;
supported by 1 or more OTSi"; config false;
description
"organization identifier that uses organizational
mode";
container OTSiG-container { }
config false; }
description
"the container contains the related list of OTSi. /*
The list could also be of only 1 element"; * Identities
list OTSi { */
key "OTSi-carrier-id"; identity type-element {
description description
"list of OTSi's under OTSi-G"; "Base identity for element type";
leaf OTSi-carrier-id { }
type int16;
description "OTSi carrier-id"; identity Fiber {
base type-element;
description
"Fiber element";
}
identity Roadm {
base type-element;
description
"Roadm element";
}
identity Edfa {
base type-element;
description
"Edfa element";
}
identity Concentratedloss {
base type-element;
description
"Concentratedloss element";
}
identity type-power-mode {
description
"power equalization mode used within the
OMS and its elements";
}
identity power-spectral-density {
base type-power-mode;
description
"all elements must use power spectral density (W/Hz)";
}
identity channel-power {
base type-power-mode;
description
"all elements must use power (dBm)";
}
/*
* Groupings
*/
grouping amplifier-params {
description "describes parameters for an amplifier";
container amplifier{
description "amplifier type, operatonal parameters
are described";
leaf type-variety {
type string ;
mandatory true ;
description
"String identifier of amplifier type referencing
a specification in a separate equipment catalog";
} }
leaf OTSi-carrier-frequency { container operational {
type decimal64 { description "amplifier operationnal parameters";
fraction-digits 3; leaf actual-gain {
type decimal64 {
fraction-digits 2;
}
units dB ;
mandatory true ;
description "..";
}
leaf tilt-target {
type decimal64 {
fraction-digits 2;
}
mandatory true ;
description "..";
}
leaf out-voa {
type decimal64 {
fraction-digits 2;
}
units dB;
mandatory true;
description "..";
}
leaf in-voa {
type decimal64 {
fraction-digits 2;
}
units dB;
mandatory true;
description "..";
}
uses power-param;
} }
units GHz;
config false;
description
"OTSi carrier frequency";
} }
leaf OTSi-signal-width { }
type decimal64 {
fraction-digits 3; grouping fiber-params {
description
"String identifier of fiber type referencing a
specification in a separate equipment catalog";
container fiber {
description "fiber characteristics";
leaf type-variety {
type string ;
mandatory true ;
description "fiber type";
}
leaf length {
type decimal64 {
fraction-digits 2;
}
units km;
mandatory true ;
description "length of fiber";
}
leaf loss-coef {
type decimal64 {
fraction-digits 2;
}
units dB/km;
mandatory true ;
description "loss coefficient of the fiber";
}
leaf total-loss {
type decimal64 {
fraction-digits 2;
}
units dB;
mandatory true ;
description
"includes all losses: fiber loss and conn-in and
conn-out losses";
}
leaf pmd{
type decimal64 {
fraction-digits 2;
}
units sqrt(ps);
description "pmd of the fiber";
}
leaf conn-in{
type decimal64 {
fraction-digits 2;
}
units dB;
description "connector-in";
}
leaf conn-out{
type decimal64 {
fraction-digits 2;
}
units dB;
description "connector-out";
} }
units GHz;
config false;
description
"OTSi signal width";
} }
leaf channel-delta-power { }
type decimal64 {
fraction-digits 2; grouping roadm-express-path {
description "roadm express path optical impairments";
container roadm-express-path {
description "roadm parameters per express path";
leaf roadm-pmd {
type decimal64 {
fraction-digits 8;
range "0..max";
}
units "ps/(km)^0.5";
description
"Polarization Mode Dispersion";
} }
units dB; leaf roadm-cd {
config false; type decimal64 {
fraction-digits 5;
}
units "ps/nm";
description "Chromatic Dispersion";
}
leaf roadm-pdl {
type decimal64 {
fraction-digits 2;
}
units dB ;
description "Polarization dependent loss";
}
leaf roadm-inband-crosstalk {
type decimal64 {
fraction-digits 2;
}
units dB;
description
"In-band crosstalk, or coherent crosstalk, can occur in
components that can have multiple same wavelength inputs
with the inputs either routed to different output ports,
or all but 1 blocked";
}
leaf roadm-maxloss {
type decimal64 {
fraction-digits 2;
}
units dB;
description
"This is the maximum expected add path loss from the
ROADM ingress to the ROADM egress
assuming no additional add path loss is added";
}
}
}
grouping roadm-add-path {
description "roadm add block path optical impairments";
container roadm-add-path {
description "roadm optical impairment parameters
per add path";
leaf roadm-pmd {
type decimal64 {
fraction-digits 8;
range "0..max";
}
units "ps";
description
"Polarization Mode Dispersion";
}
leaf roadm-cd {
type decimal64 {
fraction-digits 5;
}
units "ps/nm";
description "Cromatic Dispersion";
}
leaf roadm-pdl {
type decimal64 {
fraction-digits 2;
}
units dB ;
description "Polarization dependent loss";
}
leaf roadm-inband-crosstalk {
type decimal64 {
fraction-digits 2;
}
units dB ;
description
"In-band crosstalk, or coherent crosstalk,
can occur in components that can have multiple same
wavelength inputs,with the inputs either
routed to different output ports,
or all but 1 blocked.
In the case of add path it is the total
of the add block
+ egress WSS crosstalk contributions.";
}
leaf roadm-maxloss {
type decimal64 {
fraction-digits 2;
}
units dB ;
description
"This is the maximum expected add path loss from
the add/drop port input to the ROADM egress,
assuming no additional add path loss is added.
This is used to establish the minimum required
transponder output power required
to hit the ROADM egress target power
levels and preventing
to hit the WSS attenuation limits.
If the add path contains an internal amplifier
this loss value should be based
on worst case expected amplifier gain due to
ripple or gain uncertainty";
}
leaf roadm-pmax {
type decimal64 {
fraction-digits 2;
}
units dBm ;
description
"This is the maximum (per carrier) power level
permitted at the add block input ports,
that can be handled by the ROADM node.
This may reflect either add amplifier power
contraints or WSS adjustment limits.
Higher power transponders would need to have
their launch power reduced
to this value or lower";
}
leaf roadm-osnr {
type decimal64 {
fraction-digits 5;
}
units "dB";
description
"Optical Signal-to-Noise Ratio (OSNR).
If the add path contains the ability to adjust the
carrier power levels into an add path amplifier
(if present) to a target value,
this reflects the OSNR contribution of the
add amplifier assuming this target value is obtained.
The worst case OSNR based on the input power and
NF calculation method, and this value, should be used
(if both are defined).";
}
leaf roadm-noise-figure {
type decimal64 {
fraction-digits 5;
}
units "dB";
description
"Noise Figure. If the add path contains an amplifier,
this is the noise figure of that amplifier inferred
to the add port.
This permits add path OSNR calculation based
on the input power levels to the add block
without knowing the ROADM path losses to
the add amplifier.";
}
}
}
grouping roadm-drop-path {
description "roadm drop block path optical impairments";
container roadm-drop-path {
description "roadm optical impairment parameters
per drop path";
leaf roadm-pmd {
type decimal64 {
fraction-digits 8;
range "0..max";
}
units "ps/(km)^0.5";
description
"Polarization Mode Dispersion";
}
leaf roadm-cd {
type decimal64 {
fraction-digits 5;
}
units "ps/nm";
description "Chromatic Dispersion";
}
leaf roadm-pdl {
type decimal64 {
fraction-digits 2;
}
units dB ;
description "Polarization dependent loss";
}
leaf roadm-inband-crosstalk {
type decimal64 {
fraction-digits 2;
}
units dB;
description
"In-band crosstalk, or coherent crosstalk, can occur in
components that can have multiple same wavelength
inputs,with the inputs either routed to different
output ports,or all but 1 blocked.
In the case of drop path it is the total
of the ingress
to drop e.g. WSS and drop block crosstalk
contributions.";
}
leaf roadm-maxloss {
type decimal64 {
fraction-digits 2;
}
units dB ;
description
"The net loss from the ROADM input,to the output
of the drop block.
If ROADM ingress to drop path includes an amplifier,
the amplifier gain reduces the net loss.
This is before any additional drop path attenuation
that may be required
due to drop amplifier power contraints.
The max value correspond to worst case expected loss,
including amplifier gain ripple or uncertainty.
It is the maximum output power of the drop
amplifier.";
}
leaf roadm-minloss {
type decimal64 {
fraction-digits 2;
}
units dB ;
description
"The net loss from the ROADM input, to the
output of the drop block.
If this ROADM ingress to drop path includes
an amplifier,the amplifier gain reduces the net loss.
This is before any additional drop path attenuation
that may be required due to drop amplifier power
contraints.
The min value correspond to best case expected loss,
including amplifier gain ripple or uncertainty.";
}
leaf roadm-typloss {
type decimal64 {
fraction-digits 2;
}
units dB ;
description
"The net loss from the ROADM input,
to the output of the drop block.
If this ROADM ingress to drop path
includes an amplifier,
the amplifier gain reduces the net loss.
This is before any additional drop path
attenuation
that may be required due to drop amplifier
power contraints.
The typ value correspond to typical case
expected loss.";
}
leaf roadm-pmin {
type decimal64 {
fraction-digits 2;
}
units dBm ;
description
"If the drop path has additional loss
that is added, for example,
to hit target power levels into a
drop path amplifier, or simply, to reduce the
power of a "strong" carrier
(due to ripple,for example),
then the use of the ROADM input power levels and
the above drop losses is not appropriate.
This parameter corresponds to the min per
carrier power levels
expected at the output of the drop block.
A detail example of the comparison using
these parameters is
detailed in section xxx of the document yyy.";
}
leaf roadm-pmax {
type decimal64 {
fraction-digits 2;
}
units dBm ;
description
"If the drop path has additional loss that is added,
for example, to hit target power levels into a
drop path amplifier,or simply,to reduce the power
of a "strong" carrier(due to ripple,for example),
then the use of the ROADM input power levels and the
above drop losses is not appropriate.
This parameter corresponds to the best case per
carrier power levels expected at the output of the
drop block.
A detail example of the comparison using
these parameters
is detailed in section xxx of the document yyy";
}
leaf roadm-ptyp {
type decimal64 {
fraction-digits 2;
}
units dBm ;
description
"If the drop path has additional loss that is added,
for example, to hit target power levels into a
drop path amplifier,or simply,to reduce the
power of a "strong" carrier(due to ripple,for example),
then the use of the ROADM input power levels and
the above drop losses is not appropriate.
This parameter corresponds to the typical case
per carrier power levels expected
at the output of the drop block.";
}
leaf roadm-osnr {
type decimal64 {
fraction-digits 5;
}
units "dB";
description
"Optical Signal-to-Noise Ratio (OSNR).
Expected OSNR contribution of the drop path
amplifier(if present)
for the case of additional drop path loss
(before this amplifier)
in order to hit a target power level (per carrier).
If both, the OSNR based on the ROADM
input power level
(Pcarrier =
Pref+10Log(carrier-baudrate/ref-baud) + delta-power)
and the input inferred NF(NF.drop),
and this OSNR value, are defined,
the minimum value between these two should be used";
}
leaf roadm-noise-figure {
type decimal64 {
fraction-digits 5;
}
units "dB";
description
"Drop path Noise Figure.
If the drop path contains an amplifier,
this is the noise figure
of that amplifier, inferred to the
ROADM ingress port.
This permits to determine
amplifier OSNR contribution
without having to specify the
ROADM node's losses to that amplifier.
This applies for the case of no
additional drop path loss,
before the amplifier, in order to reduce the power
of the carriers to a target value";
}
}
}
grouping concentratedloss-params{
description "concentrated loss";
container concentratedloss{
description "concentrated loss";
leaf loss {
type decimal64 {
fraction-digits 2;
}
units dB ;
description "..";
}
}
}
grouping power-param{
description
"optical power or PSD after the ROADM or after the out-voa";
choice power-param {
description description
"optional ; delta power to ref channel input-power applied "select the mode: channel power or power spectral density";
to this media channel"; case channel-power {
/* when "equalization-mode='channel-power'"; */
leaf nominal-channel-power{
type decimal64 {
fraction-digits 1;
}
units dBm ;
description
" Reference channel power after the ROADM or after
the out-voa. ";
}
}
case power-spectral-density{
/* when "equalization-mode='power-spectral-density'"; */
leaf nominal-power-spectral-density{
type decimal64 {
fraction-digits 16;
}
units W/Hz ;
description
" Reference power spectral density after
the ROADM or after the out-voa.
Typical value : 3.9 E-14, resolution 0.1nW/MHz";
}
}
} }
}
grouping oms-general-optical-params {
description "OMS link optical parameters";
leaf generalized-snr {
type decimal64 {
fraction-digits 5;
}
units "dB@0.1nm";
description "generalized snr";
}
leaf equalization-mode{
type identityref {
base type-power-mode;
}
mandatory true;
description "equalization mode";
}
uses power-param;
} }
} // OTSiG container
} // OTSiG grouping
grouping media-channel-groups { grouping OTSiG {
description "media channel groups"; description "OTSiG definition , representing client
list media-channel-group { digital information stream supported by 1 or more OTSi";
key "i";
description
"list of media channel groups";
leaf i {
type int16;
description "index of media channel group member";
}
list media-channels { container OTSiG-container {
key "flexi-n"; config false;
description description
"list of media channels represented as (n,m)"; "the container contains the related list of OTSi.
uses layer0-types:flexi-grid-channel; The list could also be of only 1 element";
leaf OTSiG-ref { list OTSi {
type leafref { key "OTSi-carrier-id";
path "/nw:networks/nw:network/nw:node/tet:te" + description
"/tet:tunnel-termination-point/OTSiG-element/OTSiG-identifier" ; "list of OTSi's under OTSi-G";
leaf OTSi-carrier-id {
type int16;
description "OTSi carrier-id";
}
leaf OTSi-carrier-frequency {
type decimal64 {
fraction-digits 3;
}
units GHz;
config false;
description
"OTSi carrier frequency";
} }
description leaf OTSi-signal-width {
"Reference to the OTSiG list to get OTSiG identifier of the type decimal64 {
OSiG carried by this media channel that reports the transient stat"; fraction-digits 3;
} }
leaf OTSi-ref { units GHz;
type leafref { config false;
path "/nw:networks/nw:network/nw:node/tet:te" + description
"/tet:tunnel-termination-point/OTSiG-element[OTSiG- "OTSi signal width";
identifier=current()/../OTSiG-ref]/"+
"OTSiG-container/OTSi/OTSi-carrier-id" ;
} }
description leaf channel-delta-power {
"Reference to the OTSi list supporting the related OTSiG" ; type decimal64 {
fraction-digits 2;
}
units dB;
config false;
description
"optional ; delta power to ref channel
input-power applied
to this media channel";
}
} }
} // OTSiG container
} // OTSiG grouping
} // media channels list grouping media-channel-groups {
} // media-channel-groups list description "media channel groups";
} // media media-channel-groups grouping list media-channel-group {
key "i";
description
"list of media channel groups";
leaf i {
type int16;
description "index of media channel group member";
}
grouping oms-element { list media-channels {
description "OMS description"; key "flexi-n";
list OMS-elements { description
key "elt-index"; "list of media channels represented as (n,m)";
uses layer0-types:flexi-grid-channel;
leaf OTSiG-ref {
type leafref {
path "/nw:networks/nw:network/nw:node/tet:te" +
"/tet:tunnel-termination-point" +
"/OTSiG-element/OTSiG-identifier" ;
}
description
"Reference to the OTSiG list to get OTSiG
identifier of the
OSiG carried by this media channel
that reports the transient stat";
}
leaf OTSi-ref {
type leafref {
path "/nw:networks/nw:network/nw:node/tet:te" +
"/tet:tunnel-termination-point/"
+"OTSiG-element[OTSiG-identifier=current()"
+"/../OTSiG-ref]/"
+ "OTSiG-container/OTSi/OTSi-carrier-id" ;
}
description
"Reference to the OTSi list supporting the
related OTSiG" ;
}
} // media channels list
} // media-channel-groups list
} // media media-channel-groups grouping
grouping oms-element {
description "OMS description";
list OMS-elements {
key "elt-index";
description
"defines the spans and the amplifier blocks of
the amplified lines";
leaf elt-index {
type uint16;
description
"ordered list of Index of OMS element
(whether it's a Fiber, an EDFA or a
Concentratedloss)";
}
leaf uid {
type string;
description
"unique id of the element if it exists";
}
leaf type {
type identityref {
base type-element;
}
mandatory true;
description "element type";
}
container element {
description "element of the list of elements of the OMS";
choice element {
description "OMS element type";
case amplifier {
/* when "type = 'Edfa'"; */
uses amplifier-params ;
}
case fiber {
/* when "type = 'Fiber'"; */
uses fiber-params ;
}
case concentratedloss {
/* when "type = 'Concentratedloss'"; */
uses concentratedloss-params ;
}
}
}
}
}
/* Data nodes */
augment "/nw:networks/nw:network/nw:network-types"
+ "/tet:te-topology" {
description "optical-impairment topology augmented";
container optical-impairment-topology {
presence "indicates an impairment-aware topology of
optical networks";
description description
"defines the spans and the amplifier blocks of the amplified lines"; "Container to identify impairment-aware topology type";
leaf elt-index { }
type uint16; }
description
"ordered list of Index of OMS element (whether it's a Fiber, an EDFA or a augment "/nw:networks/nw:network/nt:link/tet:te"
Concentratedloss)"; + "/tet:te-link-attributes" {
} when "/nw:networks/nw:network/nw:network-types"
leaf uid { +"/tet:te-topology/"
type string; +"optical-imp-topo:optical-impairment-topology" {
description description
"unique id of the element if it exists"; "This augment is only valid for Optical Impairment.";
} }
leaf type { description "Optical Link augmentation for impairment data.";
type identityref { container OMS-attributes {
base type-element; config false;
} description "OMS attributes";
mandatory true; uses oms-general-optical-params;
description "element type"; uses media-channel-groups;
uses oms-element;
} }
}
container element { augment "/nw:networks/nw:network/nw:node/tet:te"
description "element of the list of elements of the OMS"; + "/tet:tunnel-termination-point" {
choice element { when "/nw:networks/nw:network/nw:network-types"
description "OMS element type"; +"/tet:te-topology/optical-imp-topo:optical-impairment-topology"{
case amplifier { description
/* when "type = 'Edfa'"; */ "This augment is only valid for Impairment with non-sliceable
uses amplifier-params ; transponder model";
} }
case fiber { description
/* when "type = 'Fiber'"; */ "Tunnel termination point augmentation for non-sliceable
uses fiber-params ; transponder model.";
list OTSiG-element {
key "OTSiG-identifier";
config false;
description
"the list of possible OTSiG representing client digital
stream";
leaf OTSiG-identifier {
type int16;
description "index of OTSiG element";
} }
case concentratedloss { uses OTSiG;
/* when "type = 'Concentratedloss'"; */ }
uses concentratedloss-params ;
list transponders-list {
key "transponder-id";
config false;
description "list of transponders";
leaf transponder-id {
type uint32;
description "transponder identifier";
} }
} choice mode {
} description "standard mode, organizational mode or
} explicit mode";
}
/* Data nodes */ case G.692.2 {
uses standard-mode;
augment "/nw:networks/nw:network/nw:network-types" }
+ "/tet:te-topology" {
description "optical-impairment topology augmented";
container optical-impairment-topology {
presence "indicates an impairment-aware topology of optical networks";
description
"Container to identify impairment-aware topology type";
}
}
augment "/nw:networks/nw:network/nt:link/tet:te" case organizational-mode {
+ "/tet:te-link-attributes" { uses organizational-mode;
when "/nw:networks/nw:network/nw:network-types" }
+"/tet:te-topology/optical-imp-topo:optical-impairment-topology" {
description case explicit-mode {
"This augment is only valid for Optical Impairment."; uses transponder-attributes;
} }
description "Optical Link augmentation for impairment data."; }
container OMS-attributes {
config false; leaf power {
description "OMS attributes"; type int32;
uses oms-general-optical-params; units "dBm";
uses media-channel-groups; config false;
uses oms-element; description "per channel power";
}
leaf power-min {
type int32;
units "dBm";
config false;
description "minimum power of the transponder";
}
leaf power-max {
type int32;
units "dBm";
config false;
description "maximum power of the transponder";
}
}
} }
}
augment "/nw:networks/nw:network/nw:node/tet:te" augment "/nw:networks/nw:network/nw:node/tet:te"
+ "/tet:tunnel-termination-point" { + "/tet:tunnel-termination-point" {
when "/nw:networks/nw:network/nw:network-types" when "/nw:networks/nw:network/nw:network-types"
+"/tet:te-topology/optical-imp-topo:optical-impairment-topology" { +"/tet:te-topology/"
description + "optical-imp-topo:optical-impairment-topology" {
"This augment is only valid for Impairment with non-sliceable description
transponder model"; "This augment is only valid for optical impairment
} with sliceable transponder model";
description }
"Tunnel termination point augmentation for non-sliceable description
transponder model."; "Tunnel termination point augmentation for sliceable
transponder model.";
uses sliceable-transponder-attributes;
}
augment "/nw:networks/nw:network/nw:node/tet:te"
+ "/tet:te-node-attributes" {
when "/nw:networks/nw:network/nw:network-types"
+ "/tet:te-topology"
+ "/optical-imp-topo:optical-impairment-topology" {
list OTSiG-element { description
key "OTSiG-identifier"; "This augment is only valid for Optical Impairment
topology";
}
description
"node attributes augmentantion for optical-impairment ROADM
node";
list roadm-path-impairments {
key "roadm-path-impairments-id";
config false; config false;
description "list of set of optical impairments related
to ROADM ";
leaf roadm-path-impairments-id {
type uint32;
description "index of the ROADM path-impairment list";
}
choice impairment-type {
description "type path impairment";
case roadm-express-path {
uses roadm-express-path;
}
case roadm-add-path {
uses roadm-add-path;
}
case roadm-drop-path {
uses roadm-drop-path;
}
}
} // list path impairments
} // augmentation for optical-impairment ROADM
augment "/nw:networks/nw:network/nw:node/tet:te/"
+ "tet:information-source-entry/tet:connectivity-matrices"{
when "/nw:networks/nw:network/nw:network-types"
+ "/tet:te-topology/"
+ "optical-imp-topo:optical-impairment-topology" {
description description
"the list of possible OTSiG representing client digital stream"; "This augment is only valid for Optical Impairment
topology ";
}
description
"Augment default TE node connectivity matrix information
source.";
leaf OTSiG-identifier { leaf roadm-path-impairments {
type int16; type leafref {
description "index of OTSiG element"; path "../../../tet:te-node-attributes/"
+ "roadm-path-impairments/roadm-path-impairments-id";
} }
uses OTSiG; description "pointer to the list set of ROADM optical
} impairments";
}
} // augmentation connectivity-matrices information-source
list transponders-list { augment "/nw:networks/nw:network/nw:node/tet:te/"
key "transponder-id"; + "tet:information-source-entry/tet:connectivity-matrices/"
config false; + "tet:connectivity-matrix" {
description "list of transponders"; when "/nw:networks/nw:network/nw:network-types"
leaf transponder-id { + "/tet:te-topology/"
type uint32; + "optical-imp-topo:optical-impairment-topology" {
description "transponder identifier"; description
"This augment is only valid for Optical Impairment
topology ";
}
description
"Augment TE node connectivity matrix entry information
source.";
leaf roadm-path-impairments {
type leafref {
path "../../../../tet:te-node-attributes/"
+ "roadm-path-impairments/roadm-path-impairments-id";
} }
description "pointer to the list set of ROADM optical
impairments";
}
} // augmentation connectivity-matrix information-source
choice mode { augment "/nw:networks/nw:network/nw:node/tet:te/"
description "standard mode, organizational mode or explicit mode"; + "tet:te-node-attributes/tet:connectivity-matrices" {
when "/nw:networks/nw:network/nw:network-types"
+ "/tet:te-topology/"
+ "optical-imp-topo:optical-impairment-topology" {
description
"This augment is only valid for Optical Impairment
topology ";
}
description
"Augment default TE node connectivity matrix.";
leaf roadm-path-impairments {
type leafref {
path "../../roadm-path-impairments/"
+ "roadm-path-impairments-id";
}
config false; /*the identifier in the list */
/*"roadm-path-impairments" of ROADM optical impairment*/
/*is read-only as the rest of attributes*/
description "pointer to the list set of ROADM optical
impairments";
}
} // augmentation connectivity-matrices
case G.692.2 { augment "/nw:networks/nw:network/nw:node/tet:te/"
uses standard_mode; + "tet:te-node-attributes/"
} + "tet:connectivity-matrices/tet:connectivity-matrix" {
when "/nw:networks/nw:network/nw:network-types"
+ "/tet:te-topology/"
+ "optical-imp-topo:optical-impairment-topology" {
description
"This augment is only valid for
Optical Impairment topology ";
}
case organizational_mode { description
uses organizational_mode; "Augment TE node connectivity matrix entry.";
}
case explicit_mode { leaf roadm-path-impairments {
uses transponder-attributes; type leafref {
} path "../../../roadm-path-impairments/"
+ "roadm-path-impairments-id";
} }
config false;
description "pointer to the list set of ROADM optical
impairments";
}
} // augmentation connectivity-matrix
leaf power { augment "/nw:networks/nw:network/nw:node/tet:te/"
type int32; + "tet:tunnel-termination-point/"
units "dBm"; + "tet:local-link-connectivities" {
config false;
description "per channel power"; when "/nw:networks/nw:network/nw:network-types"
+ "/tet:te-topology/"
+ "optical-imp-topo:optical-impairment-topology" {
description
"This augment is only valid for Optical Impairment topology ";
}
description
"Augment default TTP LLC.";
leaf add-path-impairments {
type leafref {
path "../../../tet:te-node-attributes/"
+ "roadm-path-impairments/roadm-path-impairments-id" ;
} }
config false;
description "pointer to the list set of ROADM optical
impairments";
}
leaf drop-path-impairments {
type leafref {
path "../../../tet:te-node-attributes/"
+ "roadm-path-impairments/roadm-path-impairments-id" ;
}
config false;
description "pointer to the list set of ROADM
optical impairments";
}
} // augmentation local-link-connectivities
leaf power-min { augment "/nw:networks/nw:network/nw:node/tet:te/"
type int32; + "tet:tunnel-termination-point/"
units "dBm"; + "tet:local-link-connectivities/"
config false; + "tet:local-link-connectivity" {
description "minimum power of the transponder";
when "/nw:networks/nw:network/nw:network-types"
+ "/tet:te-topology/"
+ "optical-imp-topo:optical-impairment-topology" {
description
"This augment is only valid for
Optical Impairment topology ";
}
description
"Augment TTP LLC entry.";
leaf add-path-impairments {
type leafref {
path "../../../../tet:te-node-attributes/"
+ "roadm-path-impairments/roadm-path-impairments-id" ;
} }
leaf power-max { config false;
type int32; description "pointer to the list set of ROADM optical
units "dBm"; impairments";
config false;
description "maximum power of the transponder"; }
leaf drop-path-impairments {
type leafref {
path "../../../../tet:te-node-attributes/"
+ "roadm-path-impairments/roadm-path-impairments-id" ;
} }
config false;
description "pointer to the list set of ROADM optical
impairments";
}
} // augmentation local-link-connectivity
} }
}
augment "/nw:networks/nw:network/nw:node/tet:te" <CODE ENDS>
+ "/tet:tunnel-termination-point" {
when "/nw:networks/nw:network/nw:network-types"
+"/tet:te-topology/optical-imp-topo:optical-impairment-topology" {
description
"This augment is only valid for optical impairment with sliceable
transponder model";
}
description
"Tunnel termination point augmentation for sliceable transponder model.";
uses sliceable-transponder-attributes;
}
}
<CODE ENDS>
5. Security Considerations 5. Security Considerations
The configuration, state, and action data defined in this document The configuration, state, and action data defined in this document
are designed to be accessed via a management protocol with a secure are designed to be accessed via a management protocol with a secure
transport layer, such as NETCONF [RFC6241]. The NETCONF access transport layer, such as NETCONF [RFC6241]. The NETCONF access
control model [RFC6536] provides the means to restrict access for control model [RFC8341] provides the means to restrict access for
particular NETCONF users to a preconfigured subset of all available particular NETCONF users to a preconfigured subset of all available
NETCONF protocol operations and content. NETCONF protocol operations and content.
A number of configuration data nodes defined in this document are A number of configuration data nodes defined in this document are
read-only; however, these data nodes may be considered sensitive or read-only; however, these data nodes may be considered sensitive or
vulnerable in some network environments (TBD). vulnerable in some network environments (TBD).
6. IANA Considerations 6. IANA Considerations
This document registers the following namespace URIs in the IETF XML This document registers the following namespace URIs in the IETF XML
registry [RFC3688]: registry [RFC3688]:
-------------------------------------------------------------------- --------------------------------------------------------------------
URI: urn:ietf:params:xml:ns:yang:ietf-optical-impairment-topology URI: urn:ietf:params:xml:ns:yang:ietf-optical-impairment-topology
Registrant Contact: The IESG. Registrant Contact: The IESG.
XML: N/A, the requested URI is an XML namespace. XML: N/A, the requested URI is an XML namespace.
-------------------------------------------------------------------- --------------------------------------------------------------------
This document registers the following YANG modules in the YANG This document registers the following YANG modules in the YANG Module
Module Names registry [RFC7950]: Names registry [RFC7950]:
-------------------------------------------------------------------- --------------------------------------------------------------------
name: ietf-optical-impairment-topology name: ietf-optical-impairment-topology
namespace: urn:ietf:params:xml:ns:yang:ietf-optical-impairment- namespace: urn:ietf:params:xml:ns:yang:ietf-optical-impairment-
topology topology
prefix: optical-imp-topo prefix: optical-imp-topo
reference: RFC XXXX (TDB) reference: RFC XXXX (TDB)
-------------------------------------------------------------------- --------------------------------------------------------------------
7. Acknowledgments 7. Acknowledgments
We thank Daniele Ceccarelli and Oscar G. De Dios for useful We thank Daniele Ceccarelli and Oscar G. De Dios for useful
discussions and motivation for this work. discussions and motivation for this work.
8. References 8. References
8.1. Normative References
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 8.1. Normative References
RFC 7950, August 2016.
[RFC8040] A. Bierman, M. Bjorklund, K. Watsen, "RESTCONF Protocol", [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 8040, January 2017. RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>.
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Access Control Model", RFC 8341, March 2018. Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>.
8.2. Informative References [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
Access Control Model", STD 91, RFC 8341,
DOI 10.17487/RFC8341, March 2018,
<https://www.rfc-editor.org/info/rfc8341>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 8.2. Informative References
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, June 2011.
[RFC6566] Y. Lee, G. Bernstein, D. Li, G. Martinelli, "A Framework [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
for the Control of Wavelength Switched Optical Networks and A. Bierman, Ed., "Network Configuration Protocol
(WSONs) with Impairments", RFC 6566, March 2012. (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>.
[RFC7446] Y. Lee, G. Bernstein, D. Li, W. Imajuku, "Routing and [RFC6566] Lee, Y., Ed., Bernstein, G., Ed., Li, D., and G.
Wavelength Assignment Information Model for Wavelength Martinelli, "A Framework for the Control of Wavelength
Switched Optical Networks", RFC 7446, Feburary 2015. Switched Optical Networks (WSONs) with Impairments",
RFC 6566, DOI 10.17487/RFC6566, March 2012,
<https://www.rfc-editor.org/info/rfc6566>.
[RFC7579] G. Bernstein, Y. Lee, D. Li, W. Imajuku, "General Network [RFC7446] Lee, Y., Ed., Bernstein, G., Ed., Li, D., and W. Imajuku,
Element Constraint Encoding for GMPLS Controlled "Routing and Wavelength Assignment Information Model for
Networks", RFC 7579, June 2015. Wavelength Switched Optical Networks", RFC 7446,
DOI 10.17487/RFC7446, February 2015,
<https://www.rfc-editor.org/info/rfc7446>.
[RFC7581] G. Bernstein, Y. Lee, D. Li, W. Imajuku, "Routing and [RFC7579] Bernstein, G., Ed., Lee, Y., Ed., Li, D., Imajuku, W., and
Wavelength Assignment Information Encoding for Wavelength J. Han, "General Network Element Constraint Encoding for
Switched Optical Networks", RFC 7581, June 2015. GMPLS-Controlled Networks", RFC 7579,
DOI 10.17487/RFC7579, June 2015,
<https://www.rfc-editor.org/info/rfc7579>.
[RFC7698] O. Gonzalez de Dios, Ed. and R. Casellas, Ed., "Framework [RFC7581] Bernstein, G., Ed., Lee, Y., Ed., Li, D., Imajuku, W., and
and Requirements for GMPLS-Based Control of Flexi-Grid J. Han, "Routing and Wavelength Assignment Information
Dense Wavelength Division Multiplexing (DWDM) Networks", Encoding for Wavelength Switched Optical Networks",
RFC 7698, November 2015. RFC 7581, DOI 10.17487/RFC7581, June 2015,
<https://www.rfc-editor.org/info/rfc7581>.
[RFC8340] M. Bjorklund, L. Berger, Ed., "YANG Tree Diagrams", RFC [RFC7698] Gonzalez de Dios, O., Ed., Casellas, R., Ed., Zhang, F.,
8340, March 2018. Fu, X., Ceccarelli, D., and I. Hussain, "Framework and
Requirements for GMPLS-Based Control of Flexi-Grid Dense
Wavelength Division Multiplexing (DWDM) Networks",
RFC 7698, DOI 10.17487/RFC7698, November 2015,
<https://www.rfc-editor.org/info/rfc7698>.
[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
and R. Wilton, "Network Management Datastore Architecture BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
(NMDA)", RFC 8342, March 2018. <https://www.rfc-editor.org/info/rfc8340>.
[RFC8345] A. Clemm, et al, "A YANG Data Model for Network [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
Topologies", RFC 8345, March 2018. and R. Wilton, "Network Management Datastore Architecture
(NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018,
<https://www.rfc-editor.org/info/rfc8342>.
[TE-TOPO] X. Liu, et al., "YANG Data Model for TE Topologies, work [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N.,
in progress: draft-ietf-teas-yang-te-topo. Ananthakrishnan, H., and X. Liu, "A YANG Data Model for
Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March
2018, <https://www.rfc-editor.org/info/rfc8345>.
[RFC8453] Ceccarelli, D. and Y. Lee, "Framework for Abstraction and [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for
Control of Traffic Engineered Networks", RFC 8453, August Abstraction and Control of TE Networks (ACTN)", RFC 8453,
2018. DOI 10.17487/RFC8453, August 2018,
<https://www.rfc-editor.org/info/rfc8453>.
[WSON-Topo] Y. Lee, Ed., "A Yang Data Model for WSON Optical [I-D.ietf-teas-yang-te-topo]
Networks", draft-ietf-ccamp-wson-yang-13, work in Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and
progress. O. Dios, "YANG Data Model for Traffic Engineering (TE)
Topologies", draft-ietf-teas-yang-te-topo-22 (work in
progress), June 2019.
[L0-Types] Y. Lee, Ed., "A YANG Data Model for Layer 0 Types", [I-D.ietf-ccamp-wson-yang]
draft-ietf-ccamp-layer0-types, work in progress. Zheng, H., Lee, Y., Guo, A., Lopezalvarez, V., and D.
King, "A YANG Data Model for WSON (Wavelength Switched
Optical Networks)", draft-ietf-ccamp-wson-yang-23 (work in
progress), November 2019.
[G.807] "Draft new Recommendation ITU-T G.807 (ex G.media)", ITU-T [I-D.ietf-ccamp-layer0-types]
Recommendation G.807, work in progress. Zheng, H., Lee, Y., Guo, A., Lopezalvarez, V., and D.
King, "A YANG Data Model for Layer 0 Types", draft-ietf-
ccamp-layer0-types-03 (work in progress), November 2019.
[G.709] "Interfaces for the Optical Transport Network (OTN)", ITU-T [I-D.ietf-ccamp-dwdm-if-param-yang]
Recommendation G.709, June 2016. Galimberti, G., Kunze, R., Hiremagalur, D., and G.
Grammel, "A YANG model to manage the optical interface
parameters for an external transponder in a WDM network",
draft-ietf-ccamp-dwdm-if-param-yang-02 (work in progress),
November 2019.
[G.694.1] "Spectral grids for WDM applications: DWDM frequency [G.807] "Generic functional architecture of the optical media
grid", ITU-T Recommendation G.694.1, February 2012. network", ITU-T Recommendation G.807 - in publication
process, February 2020.
[G.959.1] "Optical transport network physical layer interfaces", [G.709] "Interfaces for the Optical Transport Network (OTN)",
ITU-T Recommendation G.959.1, February 2012. ITU-T Recommendation G.709, June 2016.
[G.872] "Architecture of optical transport networks", ITU-T [G.694.1] "Spectral grids for WDM applications: DWDM frequency
Recommendation G.872, January 2017. grid", ITU-T Recommendation G.694.1, February 2012.
9. Contributors [G.959.1] "Optical transport network physical layer interfaces",
ITU-T Recommendation G.959.1, February 2012.
Jonas Martensson [G.872] "Architecture of optical transport networks",
RISE ITU-T Recommendation G.872, January 2017.
Email: jonas.martensson@ri.se Appendix A. Contributors
Aihua Guo Aihua Guo
Huawei Technologies Huawei Technologies
Email: aguo@futurewei.com Email: aguo@futurewei.com
Authors' Addresses Jonas Martensson
RISE
Young Lee Email: jonas.martensson@ri.se
SKKU (Sung Kyun Kwan University)
Email: younglee.tx@gmail.com Appendix B. Additional Authors
Haomian Zheng Haomian Zheng
Huawei Technologies Huawei Technologies
Email: zhenghaomian@huawei.com Email: zhenghaomian@huawei.com
Italo Busi Italo Busi
Huawei Technologies Huawei Technologies
Email: Italo.Busi@huawei.com Email: Italo.Busi@huawei.com
Nicola Sambo Nicola Sambo
Scuola Superiore Sant'Anna Scuola Superiore Sant'Anna
Email: nicosambo@gmail.com Email: nicosambo@gmail.com
Victor Lopez
Telefonica
Email: victor.lopezalvarez@telefonica.com
G. Galimberti
Cisco
Email: ggalimbe@cisco.com
Giovanni Martinelli Giovanni Martinelli
Cisco Cisco
Email: giomarti@cisco.com Email: giomarti@cisco.com
Jean Luc Auge Jean-Luc Auge
Orange Orange
Email: jeanluc.auge@orange.com Email: jeanluc.auge@orange.com
Esther Le Rouzic Esther Le Rouzic
Orange Orange
Email: esther.lerouzic@orange.com Email: esther.lerouzic@orange.com
Julien Meuric Julien Meuric
Orange Orange
Email: julien.meuric@orange.com Email: julien.meuric@orange.com
Dieter Beller
Nokia
Email: dieter.beller@nokia.com
Sergio Belotti Sergio Belotti
Nokia Nokia
Email: Sergio.belotti@nokia.com Email: Sergio.belotti@nokia.com
Griseri Enrico Griseri Enrico
Nokia Nokia
Email: enrico.griseri@nokia.com Email: Enrico.Griseri@nokia.com
Gert Grammel Gert Grammel
Juniper Juniper
Email: ggrammel@juniper.net Email: ggrammel@juniper.net
Authors' Addresses
Young Lee
SKKU (Sung Kyun Kwan University)
Email: younglee.tx@gmail.com
Victor Lopez
Telefonica
Email: victor.lopezalvarez@telefonica.com
G. Galimberti
Cisco
Email: ggalimbe@cisco.com
Dieter Beller
Nokia
Email: Dieter.Beller@nokia.com
 End of changes. 269 change blocks. 
1363 lines changed or deleted 2149 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/