A YANG Data Model for Optical Impairment-aware TopologyNokiaDieter.Beller@nokia.comOrangeesther.lerouzic@orange.comNokiaSergio.Belotti@nokia.comNokiaggalimbe56@gmail.comHuawei TechnologiesItalo.Busi@huawei.com
Routing
CCAMP Working Group
In order to provision an optical connection through optical
networks, a combination of path continuity, resource availability,
and impairment constraints must be met to determine viable and
optimal paths through the network. The determination of appropriate
paths is known as Impairment-Aware Routing and Wavelength Assignment
(IA-RWA) for a Wavelength Switched Optical Network (WSON), while it
is known as Impairment-Aware Routing and Spectrum Assignment
(IA-RSA) for a Spectrum Switched Optical Network (SSON).
This document provides a YANG data model for the impairment-aware
Traffic Engineering topology (TE topology) in optical networks.
It augments the technology agnostic YANG Data Model for TE
topologies.
The topology YANG model provides read-only topology data including
optical impairments that can be used for example by a Path
Computation Engine (PCE) for calculating an optically feasible path
for a new connection before it is established through an optical
network.
In order to provision an optical connection (an optical path)
through wavelength switched optical networks (WSONs) as defined
in or spectrum switched optical networks
(SSONs), a combination of path continuity, resource availability,
and impairment constraints must be met to determine viable and
optimal paths through the network. The determination of appropriate
paths is known as Impairment-Aware Routing and Wavelength Assignment
(IA-RWA) for WSON, while it is known as
IA-Routing and Spectrum Assigment (IA-RSA) for SSON.
An introduction to optical impairments and their impact on optical
signals (degradation) is provided in .
This document provides a YANG data model for the impairment-aware
Traffic Engineering (TE) topology in WSONs and SSONs. The YANG model
described in this document is a WSON/SSON technology-specific YANG
model based on the information model developed in
and the two encoding documents
and that developed
protocol independent encodings based on .
The intent of this document is to provide a YANG data model, that
can be utilized by a Multi-Domain Service Coordinator (MDSC) to
collect WSON or SSON impairment data from the Provisioning Network
Controllers (PNCs) to enable impairment-aware optical path
computation according to the ACTN Architecture
. The communication between controllers is
done via a NETCONF or a RESTCONF interface
.
Optical data plane interoperability, particularly for optical
transponders across multiple vendors, is a complex challenge that
typically necessitates joint engineering regardless of control and
management plane capabilities.
However, the YANG data model defined in this document provides the
essential optical impairment data required for impairment-aware
path computation including optical transponder interoperability if
it exists.
Optical data plane interoperability is outside the scope of this
document.
This document augments the generic TE topology YANG model defined
in .
The impairment-aware topology for a WSON/SSON network based on the
YANG data model defined in this document is intended to be used for
exposing the network topology including optical impairments.
Therefore, the topology information that is typically provided by a
PNC is assumed to be read-only data. This may change when the same
impairment-aware topology model is used for other optical network
use cases than exposing the network topology. For example, for a
path computation engine, where topological elements could be added
in the context of a what-if scenario analysis. This is outside of
the scope of this document.
This document defines one YANG module: ietf-optical-impairment-
topology ().
Refer to , , and
for the key terms used in
this document.
The following terms are defined in and are
not redefined here:
clientserveraugmentdata modeldata node
The terminology for describing YANG data models is found in
.
The term ROADM in this document refers to the term "multi-degree
reconfigurable optical add/drop multiplexer (MD-ROADM)" as defined
in . It does not include local optical
transponders, which can be co-located in the same physical device
(managed entity).
The term WDM-node refers to a physical device, which is managed as
a single network element.
The term WDM-TE-node refers to those parts of a WDM-node (physical
device) that are modeled as a TE-node as defined in
, which may include a ROADM and/or multiple
local optical transponders (OTs). Hence, a WDM-TE-node might only
contain OTs.
The term "WDM-TE-network" refers to a set of WDM-TE-nodes as defined
above that are interconnected via TE-links carrying WDM signals.
These TE-links may include optical amplifiers.
The term "add/drop TE-link" refers to a TE-link representing the
media channel between a transceiver's media port of a remote optical
transponder (OT) and an add/drop port of the ROADM in the adjacent
WDM-node. The add/drop TE-link typically carries a single optical
tributary signal (OTSi, i.e., a modulated optical carrier, see
).
The term "bundled add/drop TE-link" refers to the TE-link bundling
concept as defined in . Multiple component
links, add/drop TE-links in this case, are bundled into a single
bundled add/drop TE-Link.
In the context of this document, the term "layer 0" refers to the
photonic layer or WDM layer network in the architecture of the
optical transport network (OTN) as defined in ITU-T Recommendation
G.709 , ITU-T Recommendation G.872
, and ITU-T Recommendation G.807
as opposed to the electrical switching layers
of the OTN, which are typically referred to as layer 1 (L1).
The term "layer 0" may also be used for other transport network
technologies (e.g. copper-based, radio-based, or free space
optics-based, etc.), which are outside the scope of this document.
The term "muxponder" is a short for "multiplexer-transponder" and
refers to a device used in optical networking, especially in DWDM
(Dense Wavelength Division Multiplexing) systems, to combine
multiple client signals onto a single high-speed optical wavelength.
A simplified graphical representation of the data model is used in
Section 2 of this document. The meaning of the symbols in these
diagrams is defined in .
In this document, names of data nodes and other data model objects
are prefixed using the standard prefix associated with the
corresponding YANG imported modules, as shown in
.
Prefix YANG module Referenceoitietf-optical-impairment-topology[RFCXXXX]l0-typesietf-layer0-typesnwietf-networkntietf-network-topologyte-typesietf-te-typestetietf-te-topology
[Note to RFC editor: Please replace XXXX with the number
assigned to the RFC once this draft becomes an RFC.]
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
interpreted as described in BCP 14 when, and only when, they appear in
all capitals, as shown here.
The impairment-aware topology YANG model for optical networks
defined in this document is a network model as defined in
. The topology model provides read-only
network topology status information that is typically used for
path computation during service provisioning when a new service
is established on the network.
The model in this document does not provide device configuration
capabilities. Where those capabilities are needed, a device model
as defined in can be used:
defines a device
model for Dense Wavelength Division Multiplexing (DWDM) interfaces.
This section provides a description of the optical transport
network reference architecture and its relevant components and
their optical impairments needed to support impairment-aware
path computation.
shows the reference architecture.
<--------->
OMS MCG = TE-link
<-------------------------------->
BA: Booster Amplifier (or egress amplifier)
PA: Pre-Amplifier (or ingress amplifier)
ILA: In-Line Amplifier
MCG: Media Channel Group [G.807]
OTS MCG: Optical Transmission Section MCG [G.807]
OMS MCG: Optical Multiplex Section MCG [G.807]
]]>
BA (WDM-node 1) is the egress Amplifier and PA (WDM-node 2) is the
ingress amplifier for the Optical Multiplex Section Media Channel
Group (OMS MCG) in the direction from left to
right in .
According to , clause 3.2.4, a Media Channel
Group (MCG) represents "a unidirectional point-to-point
management/control abstraction that represents a set of one or more
media channels that are co-routed. A media channel group (MCG) is
bounded by a pair of media ports."
According to , an
Optical Transmission Section Media Channel Group (OTS MCG) represents
a topological construct between two adjacent amplifiers, such as:
defines an OMS MCG as "The topological
relationship between the media port on a filter or coupler where a
set of media channels are aggregated and the media port on a filter
or coupler where one or more media channel is added to or removed
from that aggregate. All of the media channels that are represented
by the OMS MCG must be carried over the same serial concatenation of
OTS MCGs and amplifiers."
An OMS MCG originates at the ROADM in the source WDM-node and
terminates at the ROADM in the destination WDM-node traversing the
Booster Amplifier (BA) and the Pre-Amplifier (PA) in the WDM-nodes
as well as the In-Line Amplifiers (ILAs) between the two WDM-nodes.
An OMS MCG can be decomposed into a sequence of OTS MCGs and
amplifiers.
An OMS MCG traverses a sequence of optical elements between the
ROADM function of two adjacent WDM-nodes as depicted in
where the OMS MCG is terminated.
These elements can be in the transmit direction: a Booster Amplifier
(BA), one or more fiber sections with in-line amplifiers (ILAs), and
a Pre-Amplifier (PA). A concentrated loss element can be used to
describe an insertion loss caused, for example, by a fiber connector
along the sequence of optical elements.
In TE-topology terms, the OMS MCG is modeled as a WDM TE-link
interconnecting two WDM-TE-nodes. A network controller can retrieve
the optical impairment data for all the WDM TE-link elements defined
in the layer-0 topology YANG model.
The optical impairments related to the link between remote optical
transponders, located in a different WDM-TE-node (an IP router with
integrated optical transponders for example), can also be modeled
as a WDM TE-link using the same optical impairments as those defined
for a WDM TE-link between WDM-TE-nodes (OMS MCG). In this scenario,
the node containing the remote optical transponders can be
considered as WDM-TE-node with termination capability only and no
switching capabilities.
A WDM TE-link is terminated on both ends by a link termination point
(LTP) as defined in .
Links between WDM nodes in optical transport networks are typically
bidirectional.
Generally, they have different impairments in the two directions and
hence they MUST be modeled as a pair of two unidirectional TE-links
following the modeling approach.
Unlike TE-links, which are unidirectional, the LTPs on either end
of the TE-link pair forming the bidirectional link, are
bidirectional as described in
and the
pair of unidirectional links are connected to the same bidirectional
LTP on either end of the link pair.
The OTSi is defined in ITU-T Recommendation G.959.1, section 3.2.4
as "Optical signal that is placed within a
network media channel for transport across the optical network. This
may consist of a single modulated optical carrier or a group of
modulated optical carriers or subcarriers."
The YANG model defined in assumes that a
single OTSi consists of a single modulated optical carrier. This
single modulated optical carrier conveys digital information.
Characteristics of the OTSi signal are modulation scheme (e.g. QPSK,
8-QAM, 16-QAM, etc.), baud rate (measure of the symbol rate), pulse
shaping (e.g. raised cosine - complying with the Nyquist inter
symbol interference criterion), etc.
Path computation needs to know the existing OTSi signals for each
OMS link in the topology to determine the optical impairment impact
of the existing OTSi signals on the optical feasibility of a new
OTSi signal and vice versa, i.e., the impact of the new OTSi on the
existing OTSi signals. For determining the optical feasibility of
the new OTSi, it is necessary to know the OTSi properties like
carrier frequency, baud rate, and signal power for all existing
OTSi signals on each OMS link.
Additionally, it is necessary for each WDM-TE-node in the network to
know the OTSi signals that are added to or dropped from a WDM
TE-link (OMS MCG) link as well as the optical power of these OTSi
signals to check whether the WDM-TE-node's optical power constraints
are met.
The impairment-aware topology YANG model for optical networks in
defines the optical OTSi properties needed
for impairment-aware path computation including the spectrum
occupied by each OTSi signal. The model also defines a pointer
(leafref) from the OTSi to the transceiver module terminating the
OTSi signal.
The OTSi signals in the YANG model are described by augmenting the
network and each OTSi signal is uniquely identified by its
otsi-carrier-id, which is unique within the scope of the OTSiG (see
below) the OTSi belongs to.
The OTSiG is defined in ITU-T Recommendation G.807
as a "set of optical tributary signals (OTSi)
that supports a single digital client".
Hence, the OTSiG is an electrical signal that is carried by one or
more OTSi's. The relationship between the OTSiG and the OTSi's is
described in , section 10.2.
The YANG model in supports both cases: the
single OTSi case where the OTSiG contains a single OTSi (see
, Figure 10-2) and the multiple OTSi case
where the OTSiG consists of more than one OTSi (see
, Figure 10-3).
From a layer 0 topology YANG model perspective, the OTSiG is a
logical construct that associates the OTSi's, which belong to the
same OTSiG. The typical application of an OTSiG consisting of more
than one OTSi is inverse 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 optical fibers and nodes and (ii) the
differential delay between the 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 100Gbps of client traffic.
All OTSiGs are described in the YANG model by augmenting the network
and each OTSiG is uniquely identified by its otsi-group-id, which is
unique within the network. Each OTSiG also contains a list of the
OTSi signals belonging to the OTSiG.
defines a "media channel" as "A media
association that represents both the topology (i.e., the path
through the media) and the resource (i.e., frequency slot or
effective frequency slot) that it occupies." In this document,
the term "channel" is occasionally used to indicate the resource
of an MC (i.e., frequency slot or effective frequency slot),
without representing topology.
In this document, an end-to-end MC is defined as a type of MC,
which is formed by the serial concatenation of all the MCs from
source transceiver media ports to destination transceiver media
ports.
This end-to-end MC is defined across all the ROADM nodes along the
end-to-end optical path with the same nominal central frequency n
and frequency slot of width m, which represents the effective
frequency slot of the end-to-end MC.
An end-to-end MC can carry a single OTSi, or multiple OTSi signals
belonging to the same OTSiG.
defines a "network media channel (NMC)"
as "a type of media channel that is formed by the serial
concatenation of all media channels between the media port of a
modulator and the media port of a demodulator". The modulator and
demodulator are integral functions of a transceiver and their media
ports do not necessarily coincide with the media port of the
transceiver, which is associated with the transceiver's physical
optical port. Due to this difference, the end-to-end MC is used in
this document based on the definition in the previous paragraph.
In , the term "end-to-end MC path" is
used to describe the topological aspect of the end-to-end MC, i.e.,
the path through the media (see: ,
section 7.1.2). This is in line with the TE path defined in
, section 3.9, where the TE path is defined
as "an ordered list of TE links and/or TE nodes on the TE topology
graph" interconnecting a pair of tunnel termination points (TTPs).
X: indicates the center of the frequency slot
]]>
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
of the MC following the flexible grid definition in
. In this model, the effective frequency
slot as defined in is equal to the frequency
slot of this MC. It is also assumed that ROADM devices
can switch MCs.
For various reasons (e.g. differential delay), it is preferred to
use a single MC for all OTSi's of the same OTSiG. It may however not
always be possible to find a single MC for carrying all OTSi's of an
OTSiG due to spectrum occupation along the OTSiG path.
ITU-T [G.807] defines the Media Channel Group MCG as
"A unidirectional point to point management/control abstraction that
represents a set of one or more media channels that are co-routed."
The YANG model in assumes that the MCG is a
logical grouping of one or more MCs that are used to carry all
OTSi's belonging to the same OTSiG.
The MCG can be considered as an association of MCs without defining
a 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
source to destination that is wide enough to accommodate all OTSi's
(modulated carriers) that belong to the same OTSiG. In such a case
the set of OTSi's belonging to a single OTSiG must be split across
2 or more MCs.
The MCG is relevant for path computation because all end-to-end MCs
belonging to the same MCG MUST be co-routed, i.e., MUST follow the
same path. Additional constraints may exist (e.g. differential
delay).
Optical amplifiers are used in WDM networks for amplifying the
optical signal in the optical domain without any optical to
electrical and electrical to optical conversion. Three major optical
amplifier technologies are existing at the time of writing:
Erbium Doped Fiber Amplifiers (EDFAs)
Raman Amplifiers
Semiconductor Optical Amplifiers (SOAs)
In today's WDM networks EDFAs and Raman amplifiers are widely used.
Raman amplifiers have become attractive due to their large spectral
gain bandwidth, which can be quite flat, with similar or even lower
noise figures compared to EDFAs. On the other hand, Raman amplifiers
consume more power and are usually more expensive than EDFAs.
Raman amplifiers are distributed amplifiers where an optical pump
signal is injected typically in opposite direction to the optical
signal that is amplified (backward pump, counter-propagating pump
light). Injecting the optical pump signal in the same direction is
also possible (forward pump, co-propagating pump light).
For optical amplifiers, the YANG model defines Raman pump light
attributes describing the direction (raman-direction) with respect
to the signal that is amplified and optical frequency and power for
the pump light source(s) contained in the raman-pump list. These
Raman amplifier-specific attributes are optional as they are only
applicable to Raman amplifiers. For determining the optical
amplifier type, i.e., to figure out whether an optical amplifier is
a Raman amplifier, the type-variety attribute is used.
Due to the distributed nature of the Raman amplifier it is difficult
to clearly separate the amplifier from the fiber span into which the
pump signal is injected. From a topology modeling perspective, the
Raman amplifier is modeled as two OMS line elements:
a passive fiber element accounting for the fiber loss only
and not the resulting loss including the Raman gain
an amplifier element providing all optical amplifier properties
(gain, tilt, etc.). On the OMS-link, the amplifier element is
placed where the pump is located and the geolocation information
also indicates the location of the pump.
Amplifiers can be classified according to their location along the
TE-link (OMS MCG). There are three basic amplifier types: In-Line
Amplifiers (ILAs), Pre-Amplifiers and Booster Amplifiers. ILAs are
separate physical devices while Pre-Amplifiers and Booster
Amplifiers are integral elements of a WDM-node. From a data modeling
perspective, node-internal details should not be modeled and should
be abstracted as much as possible. For Pre-Amplifiers and Booster
Amplifiers, however, a different approach has been taken, and they
are modeled as TE-link elements as they have the same optical
impairments as ILAs.
ILAs may have a variable optical attenuator on the ingress side
(in-voa attribute) allowing control of the input power of the WDM
signal (OMS MCG) entering the gain stage of the ILA. It may also
have a variable optical attenuator on the egress side, which allows
control of the optical power of the WDM output signal (OMS MCG) of
the ILA. The actual-gain attribute reflects the gain of the ILA gain
stage and does not include the attenuation of the in-voa and/or
out-voa.
To support the modeling of multi-band (e.g., C + L band) and
multi-stage (cascaded) amplifiers as depicted in
, the OMS element that
describes an optical amplifier may contain an unordered list of
amplifier-elements. The position of the element is based on the
following attributes:
lower-frequency and upper-frequency describing the frequency
band the set of amplifier-elements are operating in.
stage-order describing the sequential order of the cascaded
amplifier-elements for the frequency band.
The detailed representation of the amplifier stages is not always
mandatory. Abstraction is allowed as long as the optical impairments
of the multi-stage amplifier are modeled properly.
For example, the detailed representation of the cascaded elements is
needed in case the amplifier supports both amplification of the
signal as well as the DGE function described in
.
Multi-band amplifiers like the dual-band amplifier depicted in
have a band-separating
filter at the input and a band-combining multiplexer combining all
the bands at the output. These filter and multiplexer functions are
not modeled explicitly and their optical impairments are subsumed
in the optical impairments of the amplifier components.
o---+------------->| +----+ +-----+ +-->+---o--->
| | | / | | | / | |
| | |/ +---+ |/ | |
| | stage-order = 1 2 3 | |
| | | |
| | | |
| | stage-order = 1 2 3 | |
| | |\ +---+ |\ | |
| | | \ | | | \ | |
| +------------->| +----+ +-----+ +-->+ |
| | / | | | / |
| |/ +---+ |/ |
| OA1 DGE OA2 |
| | | |
| +-----------+-----------+ |
| | |
| lower/upper-frequency |
| L BAND |
| |
+-----------------------------------------------+
]]>
ILAs are placed at locations where the optical amplification of the
WDM signal is required on the TE-link (OMS MCG) between two
WDM-TE-nodes.
Geolocation information is already defined for TE nodes in
and is also beneficial for ILAs. Therefore,
the same geolocation container has been added to the amplifier
element on an OMS link containing altitude, latitude, and longitude
as optional attributes.
A Dynamic Gain Equalizer (DGE) is optical equipment that is capable
of adjusting the optical power on a per-channel basis in order to
compensate the channel power variation as a result of variable gain
or loss the DWDM signals experienced while propagating through the
network. The channel power can be configured explicitly or in the
form of power-spectral-density.
A transponder is optical equipment that sends and receives the
optical signal from a DWDM network. A transponder can have one or
more transceiver modules. A transceiver represents a transmitter and
its corresponding receiver (Tx/Rx pair) as defined in ITU-T
Recommendation G.698.2 . In addition to the
transceiver, which is terminating an OTSi signal, a transponder
typically provides additional layer 1 functionality such as, for
example, aggregation (multiplexing) of client traffic from multiple
input ports into a single OTSi signal, which is outside the scope of
this document addressing optical layer 0 aspects of transponders.
The termination of an OTSi signal by a transceiver is modeled as a
function of the tunnel termination point (TTP) as defined in
.
Because optical transport services (TE tunnels) are
typically bidirectional, a TTP is also modeled as a bidirectional
entity like the LTP described in . Moreover,
a TTP can terminate one or several OTSiG signals (tunnels) as
described in
and each
OTSiG consists of one or multiple OTSi signals as described in
.
Therefore, a TTP can be associated with multiple transceivers.
A transponder is typically characterized by its data/symbol rate
and the maximum distance the signal can travel. Other transponder
properties are for example but are not limited to: carrier frequency
range for the optical channel, output power per channel, measured
input power, modulation scheme, Forward Error Correction (FEC),
etc.
From a path computation perspective, the selection of the compatible
configuration of the source and the destination transceivers is an
important factor for optical signals to traverse through the DWDM
network.
The YANG model defines three different approaches to describe the
transceiver capabilities (called "modes") that are needed to
determine optical signal compatibility:
Standard ModesOrganizational ModesExplicit Modes
A standard mode is related to an optical specification developed
by a Standards Development Organization (SDO). Currently, the
"Standard Modes" can only be referred to ITU-T Recommendation
G.698.2 since ITU-T Recommendation G.698.2
is the only standard defining "Standard Modes" today.
Nothing is precluding, however, consideration of other
specifications provided by any other SDO in the Standard Mode
context as soon as such specifications might be available. An
application code as defined in ITU-T G.698.2
represents a standard ITU-T G.698.2 optical
interface specification towards the realization of transversely
compatible DWDM systems that it is a standard that ensures
transceivers from different vendors can work together in a DWDM
network.
Two transceivers supporting the same application code and a line
system matching the constraints, defined in ITU-T G.698.2, for that
application code will interoperate. As the characteristics are
encoded in the application code, the YANG model in this document
only defines a string, which represents that application code.
For the standard modes, some additional attributes are defined.
The most important one is the line-coding-bitrate attribute, which
was added because lists 100gpbs application
codes supporting two data formats, an OTU4 related data format and a
Flex-O related data format. The supported data formats for an
application code can be described by listing the supported data
formats via the line-coding-bitrate attribute as a transceiver
capability.
Moreover, the transceiver properties like optical carrier frequency
range, optical carrier tunability, and transmitter/receiver optical
power ranges can be described as optional attributes in case they
differ from the specification for the standard mode, i.e., as
defined in . A transceiver may support
extended optical frequency ranges or optical power ranges or a finer
optical carrier tunability. These capabilities can be described
explicitly if needed.
Organizations like operator groups, industry fora, or equipment
vendors can define their own optical interface specifications and
make use of transceiver capabilities going beyond existing
standards.
An organizational mode is identified by the organization-identifier
attribute defining the scope and an operational-mode that is
meaningful within the scope of the organization. Hence, the two
attributes MUST always be considered together. It is the
responsibility of the organization to assign operational modes and
to ensure that operational modes are unique and unambiguous within
the scope of the organization.
Two transceivers can be interconnected, if they have at least one
(organization-identifier, operational-mode) pair in common and if
the supported carrier frequency and power attributes have a matching
range. This is a necessary condition for path computation in the
context of organizational modes.
An operational mode is a transceiver preset (a configuration with
well-defined parameter values) subsuming several transceiver
properties defined by the optical interface specification - these
properties are not provided for an operational mode and are
therefore not defined in the YANG model. Examples of these
properties are:
FEC typeModulation schemeEncoding (mapping of bit patterns (code words) to symbols in the
constellation diagram)Baud rate (symbol rate)Carrier bandwidth (typically measured in GHz)
The major reason for these transceiver presets is the fact that the
attribute values typically cannot be configured independently and
are therefore advertised as supported operational mode capabilities.
It is the responsibility of the organization to assign operational
modes and to ensure that operational modes are unique and not
ambiguous within the scope of the organization.
In addition to the transceiver properties subsumed by the
operational mode, optical power and carrier frequency related
properties are modeled separately, i.e., outside of the operational
mode. This modeling approach allows transponders using different
transceiver variants (e.g. optical modules) with slightly different
power and/or frequency range properties to interoperate without
defining separate operational modes. Different optical modules
(pluggables) from different suppliers typically have slightly
different input and output power ranges or may have slightly
different carrier frequency tuning ranges.
The received channel power and the received total power are two
parameters that can be measured by the receiver and can be provided
by the transceiver in order to allow a controller to determine the
expected performance of the end-to-end service taking into account
the optical impairments along the path.
An organization MAY define the operational modes to include the
optical power and carrier frequency related properties following the
application code approach as defined in ITU-T Recommendation G.698.2
. In such a case, the explicit optical power
and carrier frequency related optional attributes should be omitted
in order to avoid redundant information in the description of the
transceiver capabilities. If these attributes are provided in
addition to the operational modes including these attribute values
implicitly, the parameter values provided explicitly replace the
implicit values and take precedence. This should, however, only be
done in exceptional cases and should be avoided whenever possible.
In case an implicitly given range is extended utilizing the explicit
optional attributes, a path computation policy rule may be applied
to select a value preferably from the range defined implicitly and
to only select a value from the extended range if no path can be
found for values in the implicitly defined range. Path computation
policy is outside the scope of this topology YANG model.
In summary, the optical power and carrier frequency related
attributes shall either be described implicitly by the operational
mode following the definition provided by that organization or shall
be described explicitly when the optical power and carrier frequency
related properties are not included in the operational mode
definition.
The explicit mode allows the encoding, explicitly, of any subset of
parameters e.g., FEC type, Modulation type, etc., to enable a
controller entity to check for interoperability by means outside
of this document. It shall be noted that using the explicit encoding
does not guarantee interoperability between two transceivers even
in case of identical parameter definitions. The explicit mode
shall therefore be used with care, but it could be useful when no
common Application Codes or Organizational Modes exist or the
constraints of common Application Codes or Organizational Modes
cannot be met by the line system.
The YANG model described in defines the
optical transceiver properties. They are divided between:
Optical transceiver capabilities, describing how it can be
configuredCurrent transceiver setting, indicating how it is currently
configured
The transceiver capabilities are described by the set of modes the
transceiver is supporting. Each mode must follow only one of the
three mode options defined in ,
, and
(choice in the YANG model).
The YANG model allows the description of the transceiver
capabilities by mixing different modes. A transceiver may support
some ITU-T application codes and in addition some organizational or
explicit modes.
A transceiver mode description comprises the following properties:
Supported transmitter tuning range with min/max nominal carrier
frequency [f_tx_min, f_tx_max]Supported transceiver tunability describing the transmitter's
frequency fine tuning granularity (the minimum distance between two
adjacent carrier frequencies in GHz)Supported transmitter power range [p_tx-min, p_tx_max]Supported receiver channel power range [p_rx-min, p_rx_max]Supported maximum total power, rx power for all channels fed
into the receiver
These optical transceiver properties are explicitly defined in the
model for explicit and organizational modes, while they are
implicitly defined for the application codes (see ITU-T G698.2
).
The set of optical impairment limits, e.g., min optical signal to
noise ratio (OSNR), max polarization mode dispersion (PMD),max
chromatic dispersion (CD), max polarization dependent loss (PDL),
quality factor (Q-factor) limit, are explicitly defined for the
explicit modes while they are defined implicitly for the
application codes and organizational modes.
The model provides information about the maximum accumulated
impairments supported by the transceiver modes (i.e.,
max-chromatic-dispersion, max-polarization-dependent-loss,
max-polarization-mode-dispersion, max-diff-group-delay). For CD,
PMD and PDL impairments, the model also supports the option to
provide more detailed OSNR penalties as a function of the
accumulated impairments (i.e., cd-penalty, pmd-penalty and
pdl-penalty). In this case the attributes providing the maximum
accumulated impairments MAY be omitted and the maximum accumulated
impairment MUST be listed in the penalty list. In case both are
present, there MUST NOT be any value in the penalty list above
the maximum accumulated impairment.
It is possible that the set of parameter values defined for an
explicit mode may also be represented in form of an organizational
mode or one or more application codes. The "compatible-modes"
container may provide two different lists with pointers to
application codes and organizational modes, respectively.
The current transponder configuration describes the properties of
the OTSi transmitted or received by the transceiver attached to a
specific transponder port.
Each OTSi has the following three pointer attributes modeled as
leafrefs:
Pointer to the transponder instance containing the transceiver
terminating the OTSiPointer to the transceiver instance terminating the OTSiPointer to the currently configured transceiver mode
Additionally, the OTSi is described by the following frequency and
optical power related attributes:
current carrier-frequencycurrently transmitted channel powercurrently received channel powercurrently received total power
Optical transponders are usually used to terminate a layer 0 tunnel
(layer 0 service) in the WDM layer. If, however, no optical path can
be found from the source transponder to the destination transponder
that is optically feasible due to the optical impairments, one or
more 3R regenerators are needed for regenerating the optical signal
in intermediate nodes. The term "3R" regenerator means:
reamplification, reshaping, retiming. As described in
, Appendix IV, a 3R regenerator terminates the
OTSi and generates a new OTSi. Depending on the 3R regenerator
capabilities, it can provide functions such as carrier frequency
translation (carrier-frequency), changes in the modulation scheme
(modulation-type) and FEC (FEC-type) while passing through the
digital signal except the FEC (the FEC is processed and errors are
corrected).
The 3R regeneration compound function is illustrated in section 10.1
of , and sections 10.3 and 10.4 provide
examples of a ROADM architecture and a photonic cross-connect
architecture including 3R regenerators.
Based on the functionality provided, 3R regenerators are considered
as topological layer 0 entities because they are needed for layer 0
path computation in case the optical impairments make it impossible
to find an optically feasible end-to-end path from the source
transponder to the destination transponder without 3R regeneration.
When an end-to-end path includes one or more 3R regenerators, the
corresponding layer 0 tunnel is subdivided into 2 or more segments
between the source transponder and the destination transponder
terminating the layer 0 tunnel.
3R regenerators are usually realized by a pair of optical
transponders, which are described in .
If a pair of optical transponders is used to perform a 3R
regeneratator function, two different configurations are possible
involving the pair of optical transceivers of the two optical
transponders:
The two transponders can be operated in a back-to-back
configuration where the transceiver of each optical transponder
receives and transmits the optical signal from/to the same segment
of the end-to-end tunnel. This means that each transceiver is
operated in a bi-directional mode.
| Receiver |---|Sig. |--->|Sig. |---| Transmitter |--->
|-------------+ | | | | +-------------|
<---| Transmitter |---|Proc.|<---|Proc.|---| Receiver |<---
|-------------+ +-----| |-----+ +-------------|
| | | |
+-----------------------+ +-----------------------+
Sig. Proc. = Signal Processing
]]>
The two transponders can be operated in a configuration where each
transponder performs the 3R regeneration function in one direction,
one in forward direction (from source to destination) and the other
in the reverse direction. In this configuration, the transceiver of
each optical transponder receives the signal from one segment and
transmits the regenerated optical signal into the adjacent segment.
This configuration is also called cross-regeneration and each
transceiver is operated in a uni-directional mode.
Implementations MAY support the change of the carrier frequency
where the receiver may operate at a different optical frequency
than the transmitter. The transceiver mode is a property of the
transceiver and is applied to the transmitter and the receiver.
Therefore, the transceiver mode is the same for the two segments
on the two sides of the 3R regeneratator realized by two
transceivers operated in the uni-directional mode.
| Receiver |---|Sig. --+ | |
|-------------+ | | | |
+---| Transmitter |---|Proc.<-+ | |
| |-------------+ +---------+ |
| | |
| +-----------------------------+
|
+----------------------------------------->
<-----------------------------------------+
|
+-----------------------------+ |
| Transceiver | |
| +---------+ +-------------| |
| | +->Sig. |---| Transmitter |---+
| | | | +-------------|
| | +--Proc.|---| Receiver |<-------
| +---------+ +-------------|
| |
+-----------------------------+
Optical Transponder 2
3R in backward direction
Sig. Proc. = Signal Processing
]]>
Since 3R regenerators are composed of an optical transponder pair,
the capability that an optical transponder can be used as a 3R
regenerator is added to the transponder capabilities. Hence, no
additional entity is required for describing 3R regenerators in the
TE-topology YANG model. The optical transponder capabilities
regarding the 3R regenerator function are described by the following
two YANG model attributes:
supported-termination-typesupported-3r-mode
The supported-termination-type attribute describes whether the
optical transponder can be used as tunnel terminating transponder
only, as 3R regenerator only, or whether it can support both
functions. The supported-3r-mode attribute describes the
configuration of the transponder pair forming the 3R regenerator.
A WSS is a device that dynamically routes individual wavelengths
from a common input fiber to any of several output ports without
converting them into electrical signals. The WSS/Filter is internal
to a ROADM device. This document does not model the internals of a
ROADM's WSS.
There are various optical fiber types defined by ITU-T. For optical
feasibility calculation, several fiber-level parameters need to be
taken into account, such as, fiber-type, length, loss coefficient,
PMD, connectors (in/out).
The loss of a fiber span can be described in two ways:
As calculated loss using the provided loss coefficient
(loss-coef) and length of the fiber.
As measured loss provided by the total-loss attribute.
The total-loss SHOULD be provided when it can be measured with a
power measurement facility at the output of the upstream node (input
of the fiber span) and a power measurement facility at the input of
the downstream node (output of the fiber span).
This measured loss typically differs from the calculated loss
because it includes all loss contributions including possible
accumulated loss due to imperfect fiber splices and connector
losses.
It can also change over time due to changing fiber conditions, e.g.,
in case of a fiber cut.
In case the total-loss cannot be measured (no power measurement
facilities in place), the total-loss defined as optional leaf in
the YANG model SHALL be omitted.
N.B.: In case of Raman amplifiers, the Raman gain SHALL NOT be
included in the measured loss to properly reflect only the loss of
the fiber span in the total-loss attribute.
ITU-T G.652 defines Standard Singlemode Fiber; G.654 Cutoff Shifted
Fiber; G.655 Non-Zero Dispersion Shifted Fiber; G.656 Non-Zero
Dispersion for Wideband Optical Transport; G.657 Bend-Insensitive
Fiber. There may be other fiber-types that need to be considered.
The WDM-node architectures in today's dense wavelength division
multiplexing (DWDM) networks can be categorized as follows:
Integrated WDM-node architecture with local optical transponders
Integrated WDM-node architecture with local optical transponders
and single channel add/drop ports for remote optical transponders
Disaggregated WDM-node architecture where the WDM-TE-node is
composed of degree, add/drop, and optical transponder subsystems
handled as separate WDM-nodes
The TE topology YANG model augmentations for DWDM networks including
optical impairments defined in
intends to cover all the 3 categories of WDM-node architectures
listed above. In the case of a disaggregated WDM-node architecture,
it is assumed that the optical domain controller already performs
some form of abstraction and presents the WDM-TE-node representing
the disaggregated WDM-nodes in the same way as an integrated
WDM-TE-node with local optical transponders if the optical
transponder subsystems and the add/drop subsystems are co-located
(short fiber links are not imposing any significant optical
impairments).
The different WDM-node architectures are briefly described and
illustrated in the following subsections.
and below show
the typical architecture of an integrated WDM-node, which contains
the optical transponders as an integral part of the WDM-node. Such
an integrated WDM-node provides DWDM interfaces as external
interfaces for interconnecting the device with its neighboring
WDM-node (see OMS MCG in ). The number of
these interfaces denote also the degree of the WDM-node. A degree
3 WDM-node for example has 3 DWDM links that interconnect the
WDM-node with 3 neighboring WDM-nodes. Additionally, the WDM-node
provides client interfaces for interconnecting the WDM-node with
client devices such as IP routers or Ethernet switches. These client
interfaces are the client interfaces of the integrated optical
transponders.
below shows the extreme case where all
optical transponders are not integral parts of the WDM-node but are
separate devices that are connected to the add/drop ports of the
WDM-node. If the optical transponders and the WDM-node are
co-located and if short single channel fiber links are used to
interconnect the optical transponders with an add/drop port of the
WDM-node, the optical domain controller MAY present these optical
transponders in the same way as local optical transponders. If,
however, the optical impairments of the single channel fiber link
between the optical transponder and the add/drop port of the
WDM-node cannot be neglected, it is necessary to represent the
fiber link with its optical impairments in the topology model. This
also implies that the optical transponders belong to a separate
TE-node.
provides a modeling
example for a configuration where the optical transponders and the
ROADM are different WDM-TE-nodes (remote OT configuration).
Some DWDM network operators are demanding WDM subsystems from their
vendors. An example is the OpenROADM project
where multiple operators and vendors are
developing related YANG models. The subsystems of a disaggregated
WDM-TE-node are:
Single degree subsystemsAdd/drop subsystemsOptical transponder subsystems
These subsystems are separate network elements and each network
element provides a separate management and control interface. The
subsystems are typically interconnected using short fiber patch
cables and form together a disaggregated WDM-TE-node. This
disaggregated WDM-TE-node architecture is depicted in
below.
As this document defines TE topology YANG model augmentations
for the TE topology YANG model provided at
the north-bound interface of the optical domain controller, it is a
valid assumption that the optical domain controller abstracts the
subsystems of a disaggregated WDM-TE-node and presents the
disaggregated WDM-TE-node in the same way as an integrated WDM-node
hiding all the interconnects that are not relevant from an external
TE topology view.
When an optical OTSi signal traverses a ROADM node, optical
impairments are imposed on the signal by various passive or active
optical components inside the ROADM node. Examples of optical
impairments are:
Chromatic dispersion (CD)Polarization mode dispersion (PMD)Polarization dependent loss (PDL)Optical amplifier noise due to amplified spontaneous emission
(ASE)In-band cross-talkFiltering effects (out of scope of this document)
A ROADM node contains a wavelength selective photonic switching
function (WSS)that can switch media channels (MCs) described in
. 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, add/drop ports are used for a single optical channel
signal (single OTSi), but principally this could also be a group of
OTSi signals (OTSiG). The optical impairments associated with these
MCs are different and the paths of the MCs inside the ROADM node can
be categorized as follows:
Express path: MC path between two line ports of the ROADM
(unidirectional)Add Path: MC path from an Add port to a line port of the ROADMDrop path: MC path from a line port to a Drop port of the ROADM
Due to the symmetrical architecture of the ROADM node, the optical
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
MUST be modeled separately.
The optical impairments associated with each of the three types of
ROADM-node-internal paths listed above are modeled as optical
impairment parameter sets. These parameter sets are modeled as an
augmentation of the te-node-attributes defined in
.
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 (see
also ), which are included in the optical
impairment parameter sets
(see tree view in ).
defines a connectivity
matrix and a 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).
The YANG model defined in this document supports the following
optical protection architectures:
Individual OTSi protection
OMS MCG protection = TE-link protection between adjacent
WDM-TE-nodes
Individual OTSi protection is a protection architecture where an
individual OTSi signal is protected as described in Appendix III of
ITU-T Recommendation G.873.1 .
This protection architecture requires specific photonic protection
functions in the optical domain that are typically provided by
specific protection hardware. These photonic protection functions
are a photonic splitter function splitting the OTSi signal in the
transmit direction and a photonic selector function selecting the
OTSi signal in the receive direction from one of the two protection
legs between the two protection functions terminating the individual
OTSi protection.
This individual OTSi protection scheme can be considered as a
photonic 1+1 protection scheme (1+1 sub-network connection
protection (SNCP) in ITU-T terminology).
To achieve short protection switching times, it is necessary that
the OTSi signals of the two legs are identical in terms of
wavelength, modulation format, FEC, etc., which means no receiver
configuration changes when a protection switch at the selector
occurs selecting the other leg. This is important when 3R
regenerators are needed between the two end-points terminating the
protected segment, which typically is end-to-end.
In case of individual OTSi protection without 3R regenerators,
two end-to-end MC paths are associated with the OTSi signal. In the
YANG model, this is modeled as leaf list of the OTSi providing the
e2e-mc-path-id for the two end-to-end MC paths associated with the
individually 1+1 protected OTSi. This scenario is depicted in
(forward direction) and
(reverse direction) below.
|
+-----------+ +-----------+
| WDM Node1 | +-----+ +-----+ | WDM Node2 |
| +----| | WDM | | WDM | |----+ |
| | -o---------->o-----o----->o-----o---------->o- | |
| OT | / | |Node3| |Node4| | \ | OT |
| +--+ | / | +-----+ +-----+ | \ | +--+ |
-o-o o-o- | | -o-o o-o-
| +--+ | \ | +-----+ +------+ +-----+ | / | +--+ |
| | \ | | WDM | | WDM | | WDM | | / | |
| | -o---->o-----o---->o------o---->o-----o---->o- | |
| +----| |Node5| | Node6| |Node7| |----+ |
| Splitter| +-----+ +------+ +-----+ |Selector |
+-----------+ +-----------+
|------------------------------------------------------->|
end-to-end MC path2
]]>
For each OMS MCG (TE-link) along the two end-to-end MC paths in the
forward direction (end-to-end MC path1 and end-to-end MC path2) as
well as the two end-to-end MC paths in the reverse direction
(end-to-end MC path1' and end-to-end MC path2'), the e2e-mc-path-id
is provided for the individually protected OTSi signal. Based on
this information, it is possible to construct the end-to-end MC
paths between the optical transponders terminating the individually
1+1 protected OTSi.
In the scenario depicted in and
, the e2e-mc-path-id of
end-to-end MC path1 and end-to-end MC path1' is provided for the
TE-links between WDM Node1 and WDM Node3, WDM Node3 and WDM Node4 as
well as WDM Node4 and WDM Node2 while the e2e-mc-path-id of
end-to-end MC path2 and end-to-end MC path2' is provided for the
TE-links between WDM Node1 and WDM Node5, WDM Node5 and WDM Node6,
WDM Node6 and WDM Node7 as well as WDM Node7 and WDM Node2.
If a 3R regenerator is crossed on one of the two legs or even on
both legs, the end-to-end MCs are terminated on both sides of the
3R regenerator. The configured-termination-type attribute set to
"3r-regeneration" SHALL be used to indicate that the transceivers
are forming a 3R regenerator instead of terminating the layer 0
tunnel (layer 0 service).
At WDM-nodes containing a 3R regenerator, the end-2-end MCs are
stitched together forming the end-to-end path for the layer 0 tunnel
(layer 0 service). This is reflected in the leaf list of the OTSi,
which now lists all e2e-mc-path-ids of the end-to-end MC paths on
the two legs of the individually 1+1 protected OTSi signal.
In the scenario depicted in
and below where a 3R
regenerator is crossed in WDM Node6 on the lower leg, the
e2e-mc-path-id leaf list has 3 entries (assumption: the same
e2e-mc-path-id can be used for the path in the forward and reverse
directions):
The e2e-mc-path-id identifying end-to-end MC path1 from WDM
Node1 via WDM Node3 and WDM Node4 to WDM Node2 as well as
end-to-end MC path1' in the reverse direction (upper leg)
The e2e-mc-path-id identifying end-to-end MC path2 from WDM
Node1 via WDM Node5 to WDM Node6 containing the 3R regenerator
as well as end-to-end MC path2' in the reverse direction (left
hand segment of the lower leg)
The e2e-mc-path-id identifying end-to-end MC path3 from WDM
Node6 containing the 3R regenerator via WDM Node7 to WDM
Node2 as well as end-to-end MC path3' in the reverse direction
(right hand segment of the lower leg)
Based on this modeling approach it is possible to identify the
end-2-end MCs stitched together at 3R regenerators on each of the
two legs of the individually protected 1+1 OTSi signal. Similarly,
for the case without 3R regenerators it is also possible to
associate two end-to-end paths in the forward and reverse directions
for the two legs between the optical transponders terminating the
individually 1+1 protected OTSi in WDM Node1 and WDM Node2,
respectively:
end-to-end MC path1 and end-to-end MC path1' (upper leg)
end-to-end MC path2 and end-to-end MC path2' stitched together
with end-to-end MC path3 and end-to-end MC path3' (lower leg)
OT and OTSi protection function are an integral part of the
WDM-TE-node
OT and OTSi protection/ROADM functions are in two adjacent
WDM-TE-nodes (remote OT)
OT and OTSi protection function are both in the adjacent
WDM-TE-node (protected remote OT)
The different use cases are described in the following sub-sections
and examples are provided as to how these uses cases can be modeled
properly using the impairment-aware TE-topology YANG data model for
optical networks.
OT and OTSi protection function are an integral part of the
WDM-TE-node
This use case is based on the architecture illustrated in
and the following entities are all
integral parts of the WDM-TE-node:
Local optical transponder
Splitter/selector protection function
ROADM function
illustrates such a WDM-TE-node
configuration in the transmit/forward direction where the protection
function is an optical splitter and
illustrates the same WDM-TE-node configuration in the receive/reverse
direction where the protection function is an optical selector
selecting one of the two incoming OTSi signals and switching to the
other incoming OTSi signal when the optical power of the selected
OTSi signal drops below a pre-defined threshold.
The TE-topology YANG model has been augmented to describe this
protection architecture. The already existing optional
protection-type leaf of the TTP associated with the optical
transceiver is used to indicate whether the TTP is protected, i.e.,
whether it is connected to a protection function or whether it is
unprotected, i.e., whether it is directly connected to an add-drop
port of the ROADM function in the WDM-TE-node.
For unprotected TTPs associated with an optical transceiver, the
local-link-connectivity list (LLCL) as defined in
describes the potential connectivity between
the TTP and the LTPs of the WDM-TE-node that are the local
end-points of the TE-links (OMS MCGs) interconnecting the
WDM-TE-node with its neighbors, also often called degrees of the
WDM-TE-node as opposed to its add-drop ports.
For protected TTPs, the local-link-connectivity list has been
augmented such that the potential connectivity can now be described
between the TTP and multiple LTPs including the related optical
impairments. Without this new capability, it was only possible to
describe the potential connectivity between a TTP and a single LTP
(unprotected case). If the optical impairments are the same for all
local-link-connectivity list entries for a particular TTP, which
is usually the case, the optical impairments should be omitted for
the additional LTPs leading to a more compact topology description.
If the optical impairments are different, however, they can be
described for each additional LTP entry separately.
A local-link-connectivity list example for a protected TTP in JSON
format is provided in .
OT and OTSi protection function are an integral part of the
WDM-TE-node (transmit direction)
o------\ | LTP 1 |
| | +----| | / | | \------o-------o->
--o-->| | Tx o--->o---o | | | |
| | +----| | \ | | | |
<-o---| | Rx o | ---o-->o---\ | Line |
| | +----| +--------+ | \ | LTP 2 |
| | | | \ o-------o->
| +------------+ internal | \ | |
| AD ports o \ | |
| | \ | Line |
| | \ | LTP 3 |
| | \---o-------o->
| o | |
| | | |
| +--------------+ |
+---------------------------------------------------------+
]]> | | Tx o | ---o<--o------\ | LPT 1 |
| | +----| | / | | \------o-------o<-
<-o---| | Rx o<---o---o | | | |
| | +----| | \ | | | |
| | TTP| | ---o<--o---\ | Line |
| +------------+ +--------+ | \ | LTP 2 |
| | \ o-------o<-
| internal | \ | |
| AD ports o \ | |
| | \ | Line |
| | \ | LTP 3 |
| | \---o-------o<-
| o | |
| | | |
| +--------------+ |
+---------------------------------------------------------+
]]> OT and OTSi protection/ROADM functions are in two adjacent
WDM-TE-node (remote OT)
This use case is based on the architecture illustrated in
where the optical transponder is not part
of the WDM-TE-node containing the ROADM function (WDM-TE-node-2) but
is part of a separate WDM-TE-node (WDM-TE-node-1) containing one or
more optical transponders (remote OTs). WDM-TE-node-2 contains:
Splitter/selector protection function
ROADM function
illustrates such a network configuration
in the transmit/forward direction showing the two WDM-TE-nodes where
the protection function is the optical splitter in WDM-TE-node-2 and
illustrates the same network
configuration in the receive/reverse direction where the protection
function is the optical selector in WDM-TE-node-2 selecting one of
the two incoming OTSi signals and switching to the other incoming
OTSi signal when the optical power of the selected OTSi signal drops
below a pre-defined threshold.
In the network configuration shown in and
, respectively, the two WDM-TE-nodes are
interconnected via a TE-link carrying a single OTSi signal.
This TE-link interconnects the remote OT with an add-drop port of
WDM-TE-node-2 and in the following the qualifier "add-drop" is used
to refer to that LTP as opposed to the line LTPs representing
degrees of WDM-TE-node-2.
Like for the protected TTP in ,
the optional protection-type leaf is used to indicate whether the
add-drop LTP is connected to a protection function and then to two
line LTPs via the ROADM function inside WDM-TE-node-2 or whether it
is connected to a single line LTP via the ROADM function inside
WDM-TE-node-2 (unprotected add-drop LTP). While the protection-type
attribute was already defined for the TTP, the YANG model has been
augmented to also support this optional attribute for the LTP.
For protected LTPs, the connectivity-matrix has been augmented such
that the potential connectivity can now be described between an
add-drop LTP and multiple line LTPs including the related optical
impairments. Without this new capability, it was only possible to
describe the potential connectivity between an add-drop LTP and a
single line LTP (unprotected case).
If the optical impairments are the same from the protected add-drop
LTP to all line LTPs, which is usually the case, the optical
impairments should be omitted for the additional LTPs leading to a
more compact connectivity matrix description. If the optical
impairments are different, however, they can be described for each
additional LTP separately.
o------\ | LTP 1 |
| | +----| |LTP| / | | \------o-------o->
--o-->| | Tx o----->o-->o---o | | | |
| | +----| | | \ | | | |
<-o---| | Rx o | | ---o-->o---\ | Line |
| | +----| | +--------+ | \ | LTP 2 |
| | | | | \ o-------o->
| +------------+ |AD LTP | \ | |
| | o----------------o \ | |
| | | | \ | Line |
| | |unprot. AD LTPs | \ | LTP 3 |
| | | | \---o-------o->
| | o----------------o | |
| | |AD LTP | | |
| | | +--------------+ |
+----------------+ +---------------------------------------+
]]> | | Tx o | | ---o<--o------\ | LTP 1 |
| | +----| | | / | | \------o-------o<-
<-o---| | Rx o<-----o<--o---o | | | |
| | +----| |AD | \ | | | |
| | TTP| |LTP| ---o<--o---\ | Line |
| +------------+ | +--------+ | \ | LTP 2 |
| | | | \ o-------o<-
| | |AD LTP | \ | |
| | o----------------o \ | |
| | | | \ | Line |
| | |unprot. AD LTPs | \ | LTP 3 |
| | | | \---o-------o<-
| | o----------------o | |
| | |AD LTP | | |
| | | +--------------+ |
+----------------+ +---------------------------------------+
]]> OT and protection function are both in an adjacent
WDM-TE-node (protected remote OT)
The use case illustrated in is similar to
the use case in . The difference
is that WDM-TE-node-1 does not contain the ROADM function but
contains:
Optical transponder function including the transceiver
Splitter/selector protection function
WDM-TE-node-1 can be a data center device or a router device that is
supporting 1+1 OTSi protection for its OTs while WDM-TE-node-2 is a
WDM-TE-node providing add-drop ports for remote OTs as depicted in
. WDM-TE-node-1 and WDM-TE-node-2 are
interconnected via two separate TE-links, each carrying a single
OTSi signal. The protection configuration for the protected TTP in
WDM-TE-node-1 can be described in the same way as for the use in
using the local-link-connectivity
list.
o----o------\ | LTP 1 |
| | +----| | /LTP| |LTP | \------o-------o->
--o-->| | Tx o-->o---o | | | | |
| | +----| | \ | |AD | | |
<-o---| | Rx o | ---o----->o----o---\ | Line |
| | +----| | LTP| |LTP | \ | LTP 2 |
| | | +--------+ | | \ o-------o->
| +------------+ | | | \ | |
| | o----o \ | |
| | |AD | \ | Line |
| | |LTPs| \ | LTP 3 |
| | | | \---o-------o->
| | o----o | |
| | | | | |
| | | +--------------+ |
+-----------------------------+ +---------------------------+
]]>
OMS MCG protection is a 1+1 protection architecture where a TE-link
representing an OMS MCG between two adjacent WDM-TE-nodes is 1+1
protected. This media layer protection type is also described in
Appendix III of .
illustrates this 1+1 OMS MCG
protection type and shows a 1+1 protected TE-link together with an
unprotected TE-link between the same two adjacent WDM-TE-nodes. The
protected TE-link in is composed of an
underlying primary and secondary TE-link. This modeling approach is
described below.
1+1 OMS MCG protection is a local protection scheme, which can be
modeled based on TE-link properties already defined in
. The 1+1 protected TE-link is associated
with the two underlying TE-links representing the physical links,
which are forming the 1+1 protection group together with the
splitter and selector functions in the adjacent WDM-TE-nodes as
depicted in . This modeling approach
is described in more detail in
.
Alternatively, it is possible to model the 1+1 OMS MCG protection
as single protected TE-link abstracting the two underlying physical
links as well as the splitter and selector functions in the two
adjacent WDM-TE-nodes. This modeling approach is described in more
detail in .
For both modeling approaches, the splitter and selector functions
are not represented as separate entities in the model. Their optical
impairments can be included in the optical impairments of the ROADM
paths in the two adjacent WDM-TE-nodes (connectivity matrix and
LLCL, respectively) or in the optical impairments of the 1+1
protected TE-link abstracting the two underlying physical OMS links.
o-------->o--> | | | |
| | | | / | prim. | \ | | | |
| | o-->o--o | | o--o-->o | |
| | | | \ | second.| / | | | |
| | | | -->o-------->o--> | | | |
| | | +-------+ +-------+ | | |
| | | Selector| Line 1 |Splitter | | |
| | | +-------+ +-------+ | | |
| | | | <--o<--------o<-- | | | |
| | | | / | prim. | \ | | | |
| | o<--o--o | | o--o<--o | |
| | | | \ | second.| / | | | |
| | | | <--o<--------o<-- | | | |
| | | +-------+ TE-link +-------+ | | |
| | | | | | | |
| | | | unprot. | | | |
| | o---------->o-------->o---------->o | |
| | | | Line 2 | | | |
| | o<----------o<--------o<----------o | |
| | | | TE-link | | | |
| | | | | | | |
| +-------+ | | +-------+ |
| | | |
+-----------------------+ +-----------------------+
]]>
This modeling approach models the 1+1 protected TE-link as an
additional TE-link entity on top of the primary and secondary
TE-link between the two adjacent WDM-TE-nodes terminating the
1+1 OMS MCG protection group formed by these two TE-links and the
splitter and selector functions in the two nodes. This 1+1 protected
TE-link is associated with underlying primary and secondary TE-links
forming the 1+1 protection group. The following "te-link-attributes"
already defined in and
can be used for
modeling the 1+1 protected TE-link ("te-link-attributes")
augmentation copied from :
These attributes are used as follows:
"underlay": the presence of this container indicates that an
underlying protection scheme exists
"enabled": (boolean) is set to 'true'
"primary-path": is referencing the primary OMS MCG (TE-link)
"backup-path": is referencing the secondary OMS MCG (TE-link)
"link-protection-type" (identityref) set to
'link-protection-1-plus-1' as defined in
The optical impairments for the underlying primary and secondary
TE-link can be described as for unprotected TE-links. It MAY also be
possible to only describe the optical impairments for the 1+1
protected TE-link. In this case the optical impairments of the worst
of the two underlying TE-links shall be used. This should be
sufficient as input for path computation (worst case optical
feasibility consideration).
o---------->o--> | | | |
LTP1| | RP1| | / | prim. | \ | |RP2 | |LTP6
--->o-->o.......o-->o--o | | o--o-->o.......o-->o--->
| | | | \ | second. | / | | | |
| | | | -->o---------->o--> | | | |
| +-------+ +-------+LTP3 LTP5+-------+ +-------+ |
| | | |
+-----------------------+ +-----------------------+
--+ +--
ROADM port | | ROADM port
RP1 o---------------------------------->o RP2
| |
--+ +--
1+1 protected OMS MCG (TE-link)
between ROADM ports RP1 and RP2
underlying primary and secondary TE-links:
--+ +--
| prim. |
LTP2 o---------->o LTP4
LTP3 o---------->o LTP5
| second. |
--+ +--
connectivity matrix provides optical impairments in
forward direction between LTPs in the two WDM-TE-nodes:
* LTP1 and LTP2, * LTP4 and LTP6,
* LTP1 and LTP3 * LTP5 and LTP6
]]> and
illustrate this modeling
approach including the LTPs in WDM-TE-node-1 and WDM-TE-node-2,
respectively.
In addition to the physical view, the following TE-links are
shown in the two directions:
The 1+1 protected TE-link
The underlying primary TE-link
The underlying secondary TE-link
The optical impairments of the splitter (outgoing direction) and
the selector (incoming direction) are included in the optical
impairments described by the connectivity matrix and the local link
connectivity list for the TE node.
For the example shown in
in the forward direction, the connectivity matrix describes the
optical impairments between LPT1 and LTP2 as well as LTP1 and LTP3
for WDM-TE-node-1. Likewise, the connectivity matrix describes the
optical impairments between LPT4 and LTP6 as well as LTP5 and LTP6
in WDM-TE-node-2. The same applies to the corresponding LTPs in
the reverse direction.
This modeling approach abstracts the two physical OMS links carrying
the same OMS MCG together with the splitter and selector functions
in the two WDM-TE-nodes forming the OMS protection group into a
single TE-link. When this modeling approach is used the
"te-link-attributes" already defined in and
are used as follows:
"underlay": this container MUST NOT be present
"link-protection-type" (identityref) set to
'link-protection-1-plus-1' as defined in
The optical impairments exposed for this 1+1 protected TE-link are
typically based on the optical impairments of the worse of the two
underlying physical OMS links including the optical impairments
imposed by the splitter (outgoing direction) and selector (incoming
direction).
and
illustrate this modeling
approach where the splitter/selector in the adjacent WDM-TE-nodes,
WDM-TE-node-1 and WDM-TE-node-2, as well as the two physical OMS MCG
links are abstracted into a single 1+1 protected TE-link. This is
illustrated by the dotted line surrounding these four physical
entities in and
, respectively. Based on
this modeling approach, the ROADM port connected to the
splitter/selector function is modeled as LTP for the 1+1 protected
TE-link (LTP2 in WDM-TE-node-1 and LTP3 in WDM-TE-node-2).
In this example, the connectivity matrix describes the optical
impairments between LPT1 and LTP2 in WDM-TE-node-1. Likewise, the
connectivity matrix describes the optical impairments between LPT3
and LTP4 in WDM-TE-node-2.
o---------->o--> . | | |
LTP1| | LTP2| . / | | \ . |LTP3 | |LTP4
--->o-->o.......o-->o--o | | o--o-->o.......o-->o--->
| | | . \ | | / . | | |
| | | . -->o---------->o--> . | | |
| +-------+ +...................+.......+ +-------+ |
| | | |
+-----------------------+ +-----------------------+
--+ +--
ROADM port | | ROADM port
LTP2 o---------------------------------->o LTP3
| |
--+ +---
Splitter/Selector abstracted into
1+1 protected OMS MCG (TE-link)
connectivity matrix provides optical impairments in
forward direction between LTPs in the two WDM-TE-nodes:
* LTP1 and LTP2 * LTP3 and LTP4
]]>
Alternatively, the optical impairments imposed by the splitter and
selector in each of the two adjacent WDM-TE-nodes can also be
included in the optical impairments described by the connectivity
matrix of the two nodes instead of taking them into account as
optical impairments of the 1+1 protected TE-link.
This is illustrated in in
forward direction and in
reverse direction below.
In this case, the two physical ports on both ends of the 1+1
protected TE-link are abstracted into a single LTP, LTP2 and LTP3,
in forward direction and LTP3' and LTP2' in reverse direction.
o---------->o--> | | | |
LTP1| | | | / |LTP2 LTP3| \ | | | |LTP4
--->o-->o.......o-->o--o | | o--o-->o.......o-->o--->
| | | | \ |LTP2 LTP3| / | | | |
| | | | -->o---------->o--> | | | |
| +-------+ +-------+...........+-------+ +-------+ |
| | | |
+-----------------------+ +-----------------------+
--+ +--
| |
LTP2 o---------->o LTP3
| |
--+ +--
1+1 protected
OMS MCG (TE-link)
connectivity matrix provides optical impairments in
forward direction between LTPs in the two WDM-TE-nodes:
* LTP1 and LTP2 * LTP3 and LTP4
]]>
WG List:
Editor: Gabriele Galimberti
Editor: Le Rouzic Esther
Editor: Julien Meuric
Editor: Italo Busi
Editor: Dieter Beller
Editor: Sergio Belotti
Editor: Griseri Enrico
Editor: Roberto Manzotti
Editor: Gert Grammel ";
description
"This module contains a collection of YANG definitions for
impairment-aware optical networks.
Copyright (c) 2026 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject
to the license terms contained in, the Revised BSD
License set forth in Section 4.c of the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info).
All revisions of IETF and IANA published modules can be found
at the YANG Parameters registry group
(https://www.iana.org/assignments/yang-parameters).
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
'MAY', and 'OPTIONAL' in this document are to be interpreted as
described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
they appear in all capitals, as shown here.
This version of this YANG module is part of RFC XXXX; see
the RFC itself for full legal notices.";
// RFC Ed.: replace XXXX with actual RFC number and remove
// this note
// replace the revision date with the module publication date
// the format is (year-month-day)
revision 2026-02-26 {
description
"Initial version.";
reference
"RFC XXXX: A YANG Data Model for Impairment-aware
Optical Networks";
}
/*
* Identities
*/
identity otsi-protection {
base te-types:lsp-protection-type;
description
"Individual OTSi(G) protection LSP protection type.";
reference
"ITU-T G.873.1 v5.2 (02/2022): Optical transport network:
Linear protection, Appendix III";
}
/*
* Groupings
*/
grouping amplifier-params {
description
"Describes parameters for an amplifier.";
reference
"RFC XXXX: A YANG Data Model for Impairment-aware
Optical Networks, Section 2.4";
container amplifier {
description
"The attributes of an amplifier.";
leaf type-variety {
type string;
mandatory true;
description
"The type of the amplifier.
It is usually a vendor-specific string referencing
specification in a separate equipment catalog.";
}
container operational {
description
"Amplifier operational parameters.";
list amplifier-element {
key "frequency-range-id stage-order";
description
"The list of parallel amplifier elements within an
amplifier used to amplify different frequency ranges.
Two elements in the list MUST NOT have the same range
or overlapping ranges.";
uses l0-types:frequency-range-with-identifier;
leaf stage-order {
type uint8;
description
"It allows defining for each spectrum bandwidth the
cascade order of each amplifier-element.";
}
leaf name {
type string;
description
"The name of the amplifier element as specified in
the vendor's specification associated with the
type-variety.";
}
leaf type-variety {
type string;
description
"The type of the amplifier element.
It is usually a vendor-specific string referencing
specification in a separate equipment catalog.
This attribute applies only when the type-variety of
the amplifier is not sufficient to describe the
amplifier element type.";
}
container power-param {
description
"Amplifier elements typically equalize the optical
power across the amplified channels using one of the
available equalization strategies - either targeting
a specific output power, or a specific power spectral
density (PSD), after the out-voa.";
choice power-param {
mandatory true;
description
"Select the mode: channel power or power spectral
density (PSD).";
case channel-power {
leaf nominal-carrier-power {
type l0-types:power-dbm-or-unknown;
mandatory true;
description
"Reference channel power.";
}
}
case power-spectral-density {
leaf nominal-psd {
type l0-types:psd-or-unknown;
mandatory true;
description
"Reference power spectral density (PSD).";
}
}
}
} // container power-param
leaf pdl {
type l0-types:power-loss-or-unknown;
description
"Polarization Dependent Loss (PDL).";
reference
"ITU-T G.671 v9.0 (11/2025): Transmission
characteristics of optical components and
subsystems, clause 3.2.2.35
ITU-T G.Sup41 v5.0 (07/2024): Design guidelines for
optical fibre submarine cable systems,
clause 8.1.5.2.2";
}
choice amplifier-element-type {
mandatory true;
description
"Identifies whether the amplifier element is an
Optical Amplifier (OA) or a Dynamic Gain Equalizer
(DGE).";
container optical-amplifier {
description
"The attributes applicable only to amplifier
elements.";
leaf actual-gain {
type l0-types:power-gain-or-unknown;
mandatory true;
description
"The value of the gain provided by the
amplification stage of the optical amplifier.";
}
leaf in-voa {
type l0-types:power-loss-or-unknown;
description
"Loss introduced by the Variable Optical Attenuator
(VOA) at the input of the amplification stage of
the amplifier, if present.";
}
leaf out-voa {
type l0-types:power-loss-or-unknown;
description
"Loss introduced by the Variable Optical Attenuator
(VOA) at the output of the amplification stage of
the amplifier, if present.";
}
leaf tilt-target {
type l0-types:decimal-2-or-unknown;
units "dB";
mandatory true;
description
"The tilt target defined between lower and upper
frequency of the amplifier frequency range.";
}
leaf total-output-power {
type l0-types:power-dbm-or-unknown;
mandatory true;
description
"It represents the total output power measured in
the range specified by the frequency-range.
Optical power is especially needed to
re-compute/check consistency of span
(fiber + concentrated loss) loss value, with
respect to loss/gain information on elements.";
}
leaf raman-direction {
type enumeration {
enum co-propagating {
description
"Co-propagating indicates that optical pump
light is injected in the same direction to the
optical signal that is amplified
(forward pump).";
}
enum counter-propagating {
description
"Counter-propagating indicates that optical
pump light is injected in opposite direction
to the optical signal that is amplified
(backward pump).";
}
}
description
"The direction of injection of the raman pump.";
}
list raman-pump {
key "pump-id";
description
"The list of pumps for the Raman amplifier.";
leaf pump-id {
type uint16;
description
"The identifier of a pump within an amplifier
element.";
}
leaf frequency {
type l0-types:frequency-thz;
description
"The raman pump central frequency.";
}
leaf power {
type l0-types:decimal-2-or-unknown;
units "Watts";
description
"The total pump power considering a depolarized
pump at the raman pump central frequency.";
}
}
} // container optical-amplifier
container dynamic-gain-equalizer {
presence
"When present it indicates that the amplifier element
is a Dynamic Gain Equalizer (DGE).";
description
"The attributes applicable only to DEG amplifier
elements.";
list media-channel {
key "flexi-n";
description
"List of media channels represented as (n,m).";
uses l0-types:flexi-grid-frequency-slot {
refine "flexi-m" {
mandatory true;
}
}
leaf delta-power {
type l0-types:power-ratio-or-unknown;
description
"Deviation of the carrier power with respect to
the reference carrier power, to account for
power offset related to the carrier signal
spectrum width or baud rate.";
}
} // media channels list
} // container dynamic-gain-equalizer
} // choice amplifier-element-type
} // list amplifier-element
} // container operational
} // container amplifier
} // grouping amplifier-params
grouping fiber-params {
description
"String identifier of fiber type referencing a
specification in a separate equipment catalog.";
container fiber {
description
"Fiber characteristics.";
reference
"RFC XXXX: A YANG Data Model for Impairment-aware Optical
Networks, Section 2.9";
leaf type-variety {
type string;
mandatory true;
description
"The type of the fiber.
It can be a string referencing a standard document (e.g.,
ITU-T G.652) or a vendor-specific string referencing
specification in a separate equipment catalog.";
}
leaf length {
type l0-types:decimal-2-or-unknown;
units "km";
mandatory true;
description
"Length of fiber.";
}
leaf loss-coef {
type l0-types:decimal-2-or-unknown;
units "dB/km";
mandatory true;
description
"Loss coefficient of the fiber.";
}
leaf total-loss {
type l0-types:power-loss-or-unknown;
config false;
description
"The measured total loss of the fiber, which includes
all possible losses: fiber loss and conn-in and conn-out
losses.
This attribute is not present when the total loss cannot
be measured.";
}
leaf pmd {
type l0-types:decimal-2-or-unknown;
units "ps";
description
"Polarization Mode Dispersion (PMD) of the fiber.";
reference
"ITU-T G.671 v9.0 (11/2025): Transmission characteristics
of optical components and subsystems,
clause 3.2.2.37
ITU-T G.Sup41 v5.0 (07/2024): Design guidelines for
optical fibre submarine cable systems,
clause 6.2.2.3";
}
leaf conn-in {
type l0-types:power-loss-or-unknown;
description
"The loss of the connector at the input of the fiber.";
}
leaf conn-out {
type l0-types:power-loss-or-unknown;
description
"The loss of the connector at the output of the fiber.";
}
}
}
grouping roadm-common-path {
description
"The optical impairments of a ROADM which are common to all
its paths (express path, add path or drop path).";
reference
"RFC XXXX: A YANG Data Model for Impairment-aware Optical
Networks, Section 2.10.4";
leaf roadm-pmd {
type union {
type decimal64 {
fraction-digits 8;
range "0..max";
}
type l0-types:unknown-value;
}
units "ps";
description
"Polarization Mode Dispersion (PMD).";
reference
"ITU-T G.671 v9.0 (11/2025): Transmission characteristics of
optical components and subsystems,
clause 3.2.2.37
ITU-T G.Sup41 v5.0 (07/2024): Design guidelines for optical
fibre submarine cable systems,
clause 6.2.2.3";
}
leaf roadm-cd {
type l0-types:decimal-5-or-unknown;
units "ps/nm";
description
"Chromatic Dispersion (CD).";
reference
"ITU-T G.Sup41 v5.0 (07/2024): Design guidelines for optical
fibre submarine cable systems,
clause 6.2.2.4";
}
leaf roadm-pdl {
type l0-types:power-loss-or-unknown;
description
"Polarization Dependent Loss (PDL).";
reference
"ITU-T G.671 v9.0 (11/2025): Transmission characteristics of
optical components and subsystems,
clause 3.2.2.35
ITU-T G.Sup41 v5.0 (07/2024): Design guidelines for optical
fibre submarine cable systems,
clause 8.1.5.2.2";
}
leaf roadm-inband-crosstalk {
type l0-types:decimal-2-or-unknown;
units "dB";
description
"One of the basic properties of the key optical device
wavelength selective switch (WSS) is the isolation (i.e.,
the ratio between the optical power of a selected optical
channel and the leakage power of unselected channels).
In the presence of imperfect isolation, the originated
leakage signals, usually known as crosstalk signals, will
interfere with the primary signal at the receiver end,
contributing to degrade the signal quality.
This interference is particularly harmful when both the
signal and interference have the same nominal wavelength
leading to the in-band crosstalk.";
reference
"ISSN 1068-5200: A framework for analyzing in-band crosstalk
accumulation in ROADM-based optical
networks";
}
leaf roadm-maxloss {
type l0-types:power-loss-or-unknown;
description
"This is the maximum expected path loss from the
ROADM ingress to the ROADM egress
assuming no additional path loss is added.";
}
} // grouping roadm-common-path
grouping roadm-add-path {
description
"The optical impairments of a ROADM add path.";
reference
"RFC XXXX: A YANG Data Model for Impairment-aware Optical
Networks, Section 2.10.4";
uses roadm-common-path {
refine "roadm-inband-crosstalk" {
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 one blocked.
In the case of add path it is the total
of the add block + egress WSS crosstalk contributions.";
}
refine "roadm-maxloss" {
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 MUST be based on worst case expected
amplifier gain due to ripple or gain uncertainty.";
}
}
leaf roadm-pmax {
type l0-types:power-dbm-or-unknown;
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 can reflect either add amplifier power
constraints or WSS adjustment limits.
Higher power transponders would need to have
their launch power reduced to this value or lower.";
}
leaf roadm-osnr {
type l0-types:snr-or-unknown;
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, MUST be used
(if both are defined).";
reference
"ITU-T G.Sup41 v5.0 (07/2024): Design guidelines for optical
fibre submarine cable systems, clause 8.1.3";
}
leaf roadm-noise-figure {
type l0-types:decimal-5-or-unknown;
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.";
reference
"ITU-T G.Sup41 v5.0 (07/2024): Design guidelines for optical
fibre submarine cable systems, clause 8.1.3";
}
} // grouping roadm-add-path
grouping roadm-drop-path {
description
"The optical impairments of a ROADM drop path.";
uses roadm-common-path {
refine "roadm-inband-crosstalk" {
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 one blocked.
In the case of drop path it is the total
of the ingress to drop, e.g. WSS and drop block
crosstalk contributions.";
}
refine "roadm-maxloss" {
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
constraints.
The max value corresponds to the worst case expected
loss, including amplifier gain ripple or uncertainty.
It is the maximum output power of the drop amplifier.";
}
}
leaf roadm-minloss {
type l0-types:power-loss-or-unknown;
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
constraints.
The min value correspond to best case expected loss,
including amplifier gain ripple or uncertainty.";
}
leaf roadm-typloss {
type l0-types:power-loss-or-unknown;
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
constraints.
The typ value correspond to typical case expected loss.";
}
leaf roadm-pmin {
type l0-types:power-dbm-or-unknown;
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 minimum value of the Drop
Channel output power range.";
reference
"ITU-T G.680 v1.0 (07/2007): Physical transfer functions of
optical network elements, Table 8-6";
}
leaf roadm-pmax {
type l0-types:power-dbm-or-unknown;
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 maximum value of the Drop
Channel output power range.";
reference
"ITU-T G.680 v1.0 (07/2007): Physical transfer functions of
optical network elements, table 8-6";
}
leaf roadm-ptyp {
type l0-types:power-dbm-or-unknown;
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 l0-types:snr-or-unknown;
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 MUST be used.";
reference
"ITU-T G.Sup41 v5.0 (07/2024): Design guidelines for optical
fibre submarine cable systems, clause 8.1.3";
}
leaf roadm-noise-figure {
type l0-types:decimal-5-or-unknown;
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.";
reference
"ITU-T G.Sup41 v5.0 (07/2024): Design guidelines for optical
fibre submarine cable systems, clause 8.1.3";
}
} // grouping roadm-drop-path
grouping concentrated-loss-params {
description
"Concentrated loss";
container concentrated-loss {
description
"Concentrated loss";
reference
"RFC XXXX: A YANG Data Model for Impairment-aware Optical
Networks, section 2.3";
leaf loss {
type l0-types:power-loss-or-unknown;
mandatory true;
description
"Loss introduced by the concentrated loss element (e.g., a
fiber connector, a fiber splice).";
}
}
}
grouping oms-general-optical-params {
description
"The optical paramaters of an OMS link.";
reference
"RFC XXXX: A YANG Data Model for Impairment-aware Optical
Networks, Section 2.3";
leaf generalized-snr {
type l0-types:snr;
description
"Generalized SNR.";
reference
"ITU-T G.Sup41 v5.0 (07/2024): Design guidelines for optical
fibre submarine cable systems, clause 8.1.4";
}
leaf equalization-mode {
type identityref {
base l0-types:type-power-mode;
}
description
"The equalization mode.
ROADMs typically equalize the optical power across the
channels on the OMS using one of the available equalization
strategies - either targeting a specific output power, or a
specific power spectral density (PSD).
When not present it indicates that the information about
the equalization mode is not reported.
Reporting this value is needed to support optical
impairments applications.";
}
container power-param {
description
"Optical channel power or power spectral densitity (PSD)
after the ROADM.";
leaf nominal-carrier-power {
when "derived-from-or-self(../../equalization-mode, "
+ "'l0-types:carrier-power')";
type l0-types:power-dbm-or-unknown;
description
"Reference channel power.";
}
leaf nominal-psd {
when "derived-from-or-self(../../equalization-mode, "
+ "'l0-types:power-spectral-density')";
type l0-types:psd-or-unknown;
description
"Reference power spectral density (PSD).";
}
} // container power-param
} // grouping oms-general-optical-params
grouping otsi-group {
description
"The list of the OTSis contained in one OTSiG.";
reference
"RFC XXXX: A YANG Data Model for Impairment-aware Optical
Networks, Sections 2.3.1 and 2.3.2";
list otsi {
key "carrier-id";
description
"The list of the OTSis contained in one OTSiG.
The list could also be of only one element.";
leaf carrier-id {
type uint16;
description
"The identifier of the OTSi within the OTSiG.";
}
leaf carrier-frequency {
type union {
type l0-types:frequency-thz;
type l0-types:unknown-value;
}
description
"OTSi carrier frequency, equivalent to the
actual configured transmitter frequency.";
}
leaf-list e2e-mc-path-id {
type uint16;
description
"The list of the possible end-to-end Media Channel
(e2e-MC) paths associated with the OTSi which have
different optical impairments.
This list is meaningful in case the OTSi can be associated
with multiple end-to-end Media Channel (e2e-MC) paths
(e.g., when OPS protection is configured).
The list can be empty when the OTSi has only one
e2e-MC path.";
reference
"RFC XXXX: A YANG Data Model for Impairment-aware Optical
Networks, Section 2.11.1";
}
} // OTSi list
} // OTSiG grouping
grouping media-channel-groups {
description
"The list of media channel groups (MCGs) and of their
constituent media channels (MCs).
This grouping is not intended to be reused outside of this
module.";
reference
"RFC XXXX: A YANG Data Model for Impairment-aware Optical
Networks, Sections 2.3.3 and 2.3.4";
container media-channel-groups {
presence
"When present, it indicates that the list media channel
groups is reported.";
description
"The top level container for the list of media channel
groups.";
list media-channel-group {
key "otsi-group-ref";
description
"The list of media channel groups";
leaf otsi-group-ref {
type leafref {
path "../../../../../../../otsis/"
+ "otsi-group/otsi-group-id";
}
description
"Reference to the OTSiG to which the OTSis carried by
this media channel group belong to.";
}
list media-channel {
key "media-channel-id";
unique "flexi-n";
description
"The list of media channels within the media channel
group.";
leaf media-channel-id {
type int16;
description
"The identifier of media channel within media channel
group.
It may be equal to the flexi-n attribute, when the
flexi-n attribute is present.";
}
uses l0-types:flexi-grid-frequency-slot;
list otsi-ref {
key "carrier-ref";
description
"The list of references to the OTSis and their
end-to-end Media Channel (e2e-MC) paths within the
OTSiG carried by this media channel.";
leaf carrier-ref {
type leafref {
path "../../../../../../../../../otsis/"
+ "otsi-group[otsi-group-id=current()"
+ "/../../../otsi-group-ref]/"
+ "otsi/carrier-id";
}
description
"Reference to the OTSi within the OTSiG carried
by this media channel.";
}
leaf-list e2e-mc-path-ref {
type leafref {
path "../../../../../../../../../otsis/"
+ "otsi-group[otsi-group-id=current()"
+ "/../../../otsi-group-ref]/"
+ "otsi[carrier-id=current()"
+ "/../carrier-ref]/e2e-mc-path-id";
}
description
"References to the end-to-end Media Channel (e2e-MC)
paths of this OTSi which are routed through this
media channel.";
}
}
leaf delta-power {
type l0-types:power-ratio-or-unknown;
description
"Deviation from the reference carrier power defined
for the OMS.";
}
} // media channels list
} // media-channel-groups list
}
} // media media-channel-groups grouping
grouping oms-element {
description
"The list of the OMS elements, i.e., the building blocks
(e.g., fibers, amplifiers, concentrated loss) that compose the
OMS between its link termination points.";
container oms-elements {
presence
"When present, it indicates that the list of OMS elements
is reported.";
description
"The top level container for the list of OMS elements.";
list oms-element {
key "elt-index";
description
"The list of OMS elements.";
leaf elt-index {
type uint16;
description
"An index allowing sorting the elements in their physical
order along the link without constraining their position
in the list.";
}
leaf oms-element-uid {
type union {
type string;
type l0-types:unknown-value;
}
description
"Unique identifier of the OMS element, when known.";
}
container reverse-element-ref {
description
"It contains references to the elements which are
associated with this element in the reverse
direction.";
leaf link-ref {
type leafref {
path "../../../../../../../../nt:link/nt:link-id";
}
description
"The reference to the OMS link which the OMS elements
belongs to.";
}
leaf-list oms-element-ref {
type leafref {
path "../../../../../../../../nt:link[nt:link-id="
+ "current()/../link-ref]/tet:te/"
+ "tet:te-link-attributes/oms-attributes/"
+ "oms-elements/oms-element/elt-index";
}
description
"The references to the OMS elements.";
}
}
choice element {
mandatory true;
description
"OMS element type";
case amplifier {
uses tet:geolocation-container;
uses amplifier-params;
}
case fiber {
uses fiber-params;
}
case concentrated-loss {
uses concentrated-loss-params;
}
}
}
}
}
grouping otsi-ref {
description
"References to an OTSi.
This grouping is intended to be reused within the
transceiver's list only.";
leaf otsi-group-ref {
type leafref {
path "../../../../../../otsis/otsi-group/"
+ "otsi-group-id";
}
description
"The OTSiG the referenced OTSi belongs to.";
}
leaf otsi-ref {
type leafref {
path "../../../../../../otsis/otsi-group"
+ "[otsi-group-id=current()/../otsi-group-ref]/otsi/"
+ "carrier-id";
}
description
"The referenced OTSi.";
}
}
/*
* 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
"Container to identify impairment-aware topology type.";
reference
"RFC8345: A YANG Data Model for Network Topologies.";
}
}
augment "/nw:networks/nw:network" {
when './nw:network-types/tet:te-topology'
+ '/oit:optical-impairment-topology' {
description
"This augment is only valid for Optical Impairment
topology.";
}
description
"Network augmentation for optical impairments data.";
container otsis {
presence "When present, it indicates that OTSi information is
reported.";
config false;
description
"The information about the OTSis configured on the WDM-TE
link.";
list otsi-group {
key "otsi-group-id";
description
"the list of possible OTSiG representing client digital
stream.";
leaf otsi-group-id {
type string;
description
"A network-wide unique identifier of otsi-group element.
It could be structured, e.g., as a URI or as a UUID.";
}
uses otsi-group;
} // list of OTSiG
}
container templates {
config false;
description
"Templates for set of parameters which can be common to
multiple elements.";
container roadm-path-impairments-sets {
description
"The top level container for the list of the set of
optical impairments related to ROADM paths.";
list roadm-path-impairments-set {
key "roadm-path-impairments-set-id";
description
"The list of the set of optical impairments related to a
ROADM path.";
leaf roadm-path-impairments-set-id {
type string;
description
"The identifier of an element in the list of the set of
optical impairments related to a ROADM path.";
}
leaf description {
type string;
description
"The textual description of the set of optical
impairments related to a ROADM path.";
}
choice impairment-type {
description
"Type path impairment.";
case roadm-express-path {
list roadm-express-path {
key "frequency-range-id";
description
"The list of optical impairments on a ROADM express
path for different frequency ranges.
Two elements in the list MUST NOT have the same
range or overlapping ranges.";
uses l0-types:frequency-range-with-identifier;
uses roadm-common-path;
}
}
case roadm-add-path {
list roadm-add-path {
key "frequency-range-id";
description
"The list of optical impairments on a ROADM add
path for different frequency ranges.
Two elements in the list MUST NOT have the same
range or overlapping ranges.";
uses l0-types:frequency-range-with-identifier;
uses roadm-add-path;
}
}
case roadm-drop-path {
list roadm-drop-path {
key "frequency-range-id";
description
"The list of optical impairments on a ROADM add
path for different frequency ranges.
Two elements in the list MUST NOT have the same
range or overlapping ranges.";
uses l0-types:frequency-range-with-identifier;
uses roadm-drop-path;
}
}
}
} // list roadm-path-impairments-set
} // container roadm-path-impairments-sets
container explicit-transceiver-modes {
description
"The top level container for the list of the
transceivers' explicit modes.";
list explicit-transceiver-mode {
key "explicit-transceiver-mode-id";
description
"The list of the transceivers' explicit modes.";
leaf explicit-transceiver-mode-id {
type string;
description
"The identifier of the transceivers' explicit mode.";
}
uses l0-types:explicit-mode;
} // list explicit-transceiver-mode
} // container explicit-transceiver-modes
} // container templates
} // augment network
augment "/nw:networks/nw:network/nw:node" {
when '../nw:network-types/tet:te-topology'
+ '/oit:optical-impairment-topology' {
description
"This augment is only valid for Optical Impairment.";
}
description
"Node augmentation for optical impairments data.";
container transponders {
presence
"If present, it indicates that the list of transponders is
reported.";
config false;
description
"The top level container for the list of transponders.";
list transponder {
key "transponder-id";
description
"The list of transponders.";
leaf transponder-id {
type uint32;
description
"Transponder identifier.";
}
leaf termination-type-capabilities {
type enumeration {
enum tunnel-only {
description
"The transponder can only be used in an Optical
Tunnel termination configuration.";
}
enum 3r-only {
description
"The transponder can only be used in a 3R
configuration.";
}
enum 3r-or-tunnel {
description
"The transponder can be used either in an Optical
Tunnel termination configuration or in a 3R
configuration.";
}
}
description
"Describes whether the transponder can be used in an
Optical Tunnel termination configuration or in a 3R
configuration (or both).";
}
leaf supported-3r-mode {
when '(../termination-type-capabilities = "3r-only") '
+ 'or (../termination-type-capabilities = '
+ '"3r-or-tunnel")' {
description
"Applies only when the transponder supports 3R
configuration.";
}
type enumeration {
enum unidir {
description
"Unidirectional 3R configuration.";
}
enum bidir {
description
"Bidirectional 3R configuration.";
}
}
description
"Describes the supported 3R configuration type.";
}
list transceiver {
key "transceiver-id";
min-elements 1;
description
"List of transceiver related to a transponder.";
leaf transceiver-id {
type uint32;
description
"Transceiver identifier.";
}
uses l0-types:transceiver-capabilities {
augment "supported-modes/supported-mode/mode/"
+ "explicit-mode/explicit-mode" {
description
"Augment the explicit-mode container with the
proper leafref.";
leaf explicit-transceiver-mode-ref {
type leafref {
path "../../../../../../../../oit:templates"
+ "/oit:explicit-transceiver-modes"
+ "/oit:explicit-transceiver-mode"
+ "/oit:explicit-transceiver-mode-id";
}
description
"The reference to the explicit transceiver
mode template.";
}
}
}
leaf configured-mode {
type union {
type l0-types:unknown-value;
type leafref {
path "../supported-modes/supported-mode/mode-id";
}
}
description
"Reference to the configured mode for transceiver
compatibility approach.
The 'unknown' value is used to report that no mode has
been configured and there is no default mode.
When not present, the configured-mode is not reported
by the server.";
}
uses l0-types:common-transceiver-param;
container outgoing-otsi {
when '../../../../../otsis' {
description
"It applies only when the OTSi information is
reported.";
}
description
"The OTSi generated by the transceiver's transmitter.";
uses otsi-ref;
}
container incoming-otsi {
when '../../../../../otsis' {
description
"It applies only when the OTSi information is
reported.";
}
description
"The OTSi received by the transceiver's receiver.";
uses otsi-ref;
}
leaf configured-termination-type {
type enumeration {
enum unused-transceiver {
description
"The transcevier is not used.";
}
enum tunnel-termination {
description
"The transceiver is currently used in an Optical
Tunnel termination configuration.";
}
enum 3r-regeneration {
description
"The transceiver is currently used in a 3R
configuration.";
}
}
description
"Describes whether the current configuration of the
transceiver is used in an Optical Tunnel termination
configuration or in a 3R configuration.
If empty, it means that the information about the
configured-termination-type is not reported.";
}
} // end of list of transceiver
} // end list of transponder
}
container regen-groups {
presence "When present, it indicates that the list of 3R groups
is reported.";
config false;
description
"The top level container for the list of 3R groups.";
list regen-group {
key "group-id";
description
"The list of 3R groups.
Any 3R group represent a group of transponder in which an
electrical connectivity is either in place or could
be dynamically provided, to associated transponders used
for 3R regeneration.";
leaf group-id {
type uint32;
description
"Group identifier used an index to access elements in the
list of 3R groups.";
}
leaf regen-metric {
type uint32;
description
"The cost permits choice among different groups of
transponders during path computation.";
}
leaf-list transponder-ref {
type leafref {
path "../../../transponders/transponder/transponder-id";
}
description
"The list of transponders belonging to this 3R group.";
}
} // end 3R-group
}
}
augment "/nw:networks/nw:network/nt:link/tet:te"
+ "/tet:te-link-attributes" {
when '../../../nw:network-types/tet:te-topology/'
+ 'oit:optical-impairment-topology' {
description
"This augment is only valid for Optical Impairment
topology.";
}
description
"Optical Link augmentation for impairment data.";
container oms-attributes {
config false;
description
"OMS attributes.";
uses oms-general-optical-params;
uses media-channel-groups;
uses oms-element;
}
}
augment "/nw:networks/nw:network/nw:node/tet:te"
+ "/tet:tunnel-termination-point" {
when '../../../nw:network-types/tet:te-topology/'
+ 'oit:optical-impairment-topology' {
description
"This augment is only valid for Optical Impairment
topology.";
}
description
"Tunnel termination point augmentation for impairment data.";
list ttp-transceiver {
when '../../../transponders' {
description
"It applies only when the list of transponders is
reported.";
}
key "transponder-ref transceiver-ref";
config false;
min-elements 1;
description
"The list of the transceivers used by the TTP.";
leaf transponder-ref {
type leafref {
path "../../../../transponders/transponder/transponder-id";
}
description
"The reference to the transponder hosting the transceiver
of the TTP.";
}
leaf transceiver-ref {
type leafref {
path "../../../../transponders/transponder"
+ "[transponder-id=current()/../transponder-ref]/"
+ "transceiver/transceiver-id";
}
description
"The reference to the transceiver of the TTP.";
}
} // list of transceivers
} // end of augment
augment "/nw:networks/nw:network/nw:node/nt:termination-point" {
when '../../nw:network-types/tet:te-topology/'
+ 'oit:optical-impairment-topology' {
description
"This augment is only valid for Optical Impairment
topology.";
}
description
"Augment LTP";
leaf protection-type {
type identityref {
base te-types:lsp-protection-type;
}
config false;
description
"The protection type that this LTP is capable of.
When not present it indicates that the information about
the protection type is not reported.";
}
}
augment "/nw:networks/nw:network/nw:node/nt:termination-point"
+ "/tet:te" {
when '../../../nw:network-types/tet:te-topology/'
+ 'oit:optical-impairment-topology' {
description
"This augment is only valid for Optical Impairment
topology.";
}
description
"Augment TE attributes of an LTP";
leaf inter-layer-sequence-number {
type uint32;
config false;
description
"The inter-layer-sequence-number (ILSN) is used to report
additional connectivity constraints between a client layer
Link Termination Point (LTP), such as a muxponder port, and
the server layer Tunnel Termination Point (TTP).
A client service cannot be setup between two client layer
LTPs which report different values of the ILSN.
This attribute is not reported when there are no additional
connectivity constraints.
Therefore, a client service can be setup when at least one
of the two client layer LTPs does not report any ILSN or
both client layer LTPs report the same ILSN value and the
corresponding server layer TTPs have at least one common
server-layer switching capability and at least one common
client-layer switching capability.";
}
}
augment "/nw:networks/nw:network/nw:node/tet:te/"
+ "tet:information-source-entry/tet:connectivity-matrices" {
when '../../../../nw:network-types/tet:te-topology/'
+ 'oit:optical-impairment-topology' {
description
"This augment is only valid for Optical Impairment
topology.";
}
description
"Augment default TE node connectivity matrix information
source.";
leaf roadm-path-impairments-set {
type leafref {
path "../../../../../oit:templates"
+ "/oit:roadm-path-impairments-sets"
+ "/oit:roadm-path-impairments-set"
+ "/oit:roadm-path-impairments-set-id";
}
config false;
description
"Pointer to optical impairments of the associated ROADM
path.";
}
} // augmentation connectivity-matrices information-source
augment "/nw:networks/nw:network/nw:node/tet:te/"
+ "tet:information-source-entry/tet:connectivity-matrices/"
+ "tet:connectivity-matrix" {
when '../../../../../nw:network-types/tet:te-topology/'
+ 'oit:optical-impairment-topology' {
description
"This augment is only valid for Optical Impairment
topology.";
}
description
"Augment TE node connectivity matrix entry information
source.";
leaf roadm-path-impairments-set {
type leafref {
path "../../../../../../oit:templates"
+ "/oit:roadm-path-impairments-sets"
+ "/oit:roadm-path-impairments-set"
+ "/oit:roadm-path-impairments-set-id";
}
config false;
description
"Pointer to optical impairments of the associated ROADM
path.";
}
} // augmentation connectivity-matrix information-source
augment "/nw:networks/nw:network/nw:node/tet:te/"
+ "tet:te-node-attributes/tet:connectivity-matrices" {
when '../../../../nw:network-types/tet:te-topology/'
+ 'oit:optical-impairment-topology' {
description
"This augment is only valid for Optical Impairment
topology.";
}
description
"Augment default TE node connectivity matrix.";
leaf roadm-path-impairments-set {
type leafref {
path "../../../../../oit:templates"
+ "/oit:roadm-path-impairments-sets"
+ "/oit:roadm-path-impairments-set"
+ "/oit:roadm-path-impairments-set-id";
}
config false;
description
"Pointer to optical impairments of the associated ROADM
path.";
}
} // augmentation connectivity-matrices
augment "/nw:networks/nw:network/nw:node/tet:te/"
+ "tet:te-node-attributes/"
+ "tet:connectivity-matrices/tet:connectivity-matrix" {
when '../../../../../nw:network-types/tet:te-topology/'
+ 'oit:optical-impairment-topology' {
description
"This augment is only valid for Optical Impairment
topology.";
}
description
"Augment TE node connectivity matrix entry.";
leaf roadm-path-impairments-set {
type leafref {
path "../../../../../../oit:templates"
+ "/oit:roadm-path-impairments-sets"
+ "/oit:roadm-path-impairments-set"
+ "/oit:roadm-path-impairments-set-id";
}
config false;
description
"Pointer to optical impairments of the associated ROADM
path.";
}
} // augmentation connectivity-matrix
augment "/nw:networks/nw:network/nw:node/tet:te/"
+ "tet:te-node-attributes/tet:connectivity-matrices/"
+ "tet:connectivity-matrix/tet:from" {
when '../../../../../../nw:network-types/tet:te-topology/'
+ 'oit:optical-impairment-topology' {
description
"This augment is only valid for Optical Impairment
topology.";
}
description
"Augment the attributes for the 'from' LTP for the TE node
connectivity matrix entry.";
list additional-ltp {
when "derived-from-or-self(../../../../../../"
+ "nt:termination-point"
+ "[nt:tp-id=current()/../../tet:to/tet:tp-ref]/"
+ "oit:protection-type,"
+ "'oit:otsi-protection')" {
description
"This list applies only when the 'to' LTP for this
connectivity matrix entry supports individual OTSi(G)
protection.";
}
key "ltp-ref";
config false;
description
"The restricted list of the potential secondary LTPs that
can be selected when the 'from' LTP of this connectivity
matrix entry is selected as a working LTP.
If this list is empty, all the other LTPs that can reach
the 'to' LTP of this connectivity matrix entry can be
selected as secondary LTPs.";
leaf ltp-ref {
type leafref {
path "../../../../../../../nt:termination-point/nt:tp-id";
}
description
"The reference to the potential secondary LTP that can be
selected when the 'from' LTP of this connectivity matrix
entry is selected as a working LTP.";
}
leaf roadm-path-impairments-set {
type leafref {
path "../../../../../../../../oit:templates"
+ "/oit:roadm-path-impairments-sets"
+ "/oit:roadm-path-impairments-set"
+ "/oit:roadm-path-impairments-set-id";
}
description
"Pointer to optical impairments of the ROADM path between
this secondary 'from' LTP and the 'to' LTP of this
connectivity matrix entry.";
}
}
} // augmentation connectivity-matrix from
augment "/nw:networks/nw:network/nw:node/tet:te/"
+ "tet:te-node-attributes/tet:connectivity-matrices/"
+ "tet:connectivity-matrix/tet:to" {
when '../../../../../../nw:network-types/tet:te-topology/'
+ 'oit:optical-impairment-topology' {
description
"This augment is only valid for Optical Impairment
topology.";
}
description
"Augment the attributes for the 'to' LTP for the TE node
connectivity matrix entry.";
list additional-ltp {
when "derived-from-or-self(../../../../../../"
+ "nt:termination-point"
+ "[nt:tp-id=current()/../../tet:from/tet:tp-ref]/"
+ "oit:protection-type,"
+ "'oit:otsi-protection')" {
description
"This list applies only when the 'from' LTP for this
connectivity matrix entry supports individual OTSi(G)
protection.";
}
key "ltp-ref";
config false;
description
"The restricted list of the potential secondary LTPs that
can be selected when the 'to' LTP of this connectivity
matrix entry is selected as a working LTP.
If this list is empty, all the other LTPs that can be
reached from the 'from' LTP of this connectivity matrix
entry can be selected as secondary LTPs.";
leaf ltp-ref {
type leafref {
path "../../../../../../../nt:termination-point/nt:tp-id";
}
description
"The reference to the potential secondary LTP that can be
selected when the 'to' LTP of this connectivity matrix
entry is selected as a working LTP.";
}
leaf roadm-path-impairments-set {
type leafref {
path "../../../../../../../../oit:templates"
+ "/oit:roadm-path-impairments-sets"
+ "/oit:roadm-path-impairments-set"
+ "/oit:roadm-path-impairments-set-id";
}
description
"Pointer to optical impairments of the ROADM path between
the 'from' LTP of this connectivity matrix entry and this
secondary LTP.";
}
}
} // augmentation connectivity-matrix to
augment "/nw:networks/nw:network/nw:node/tet:te/"
+ "tet:tunnel-termination-point/"
+ "tet:local-link-connectivities" {
when '../../../../nw:network-types/tet:te-topology/'
+ 'oit:optical-impairment-topology' {
description
"This augment is only valid for Optical Impairment
topology.";
}
description
"Augment default TTP LLC.";
leaf add-path-impairments-set {
type leafref {
path "../../../../../oit:templates"
+ "/oit:roadm-path-impairments-sets"
+ "/oit:roadm-path-impairments-set"
+ "/oit:roadm-path-impairments-set-id";
}
config false;
description
"Pointer to optical impairments of the associated ROADM
path.";
}
leaf drop-path-impairments-set {
type leafref {
path "../../../../../oit:templates"
+ "/oit:roadm-path-impairments-sets"
+ "/oit:roadm-path-impairments-set"
+ "/oit:roadm-path-impairments-set-id";
}
config false;
description
"Pointer to optical impairments of the associated ROADM
path.";
}
} // augmentation local-link-connectivities
augment "/nw:networks/nw:network/nw:node/tet:te/"
+ "tet:tunnel-termination-point/"
+ "tet:local-link-connectivities/"
+ "tet:local-link-connectivity" {
when '../../../../../nw:network-types/tet:te-topology/'
+ 'oit:optical-impairment-topology' {
description
"This augment is only valid for Optical Impairment
topology.";
}
description
"Augment TTP LLC entry.";
leaf add-path-impairments-set {
type leafref {
path "../../../../../../oit:templates"
+ "/oit:roadm-path-impairments-sets"
+ "/oit:roadm-path-impairments-set"
+ "/oit:roadm-path-impairments-set-id";
}
config false;
description
"Pointer to optical impairments of the associated ROADM
path.";
}
leaf drop-path-impairments-set {
type leafref {
path "../../../../../../oit:templates"
+ "/oit:roadm-path-impairments-sets"
+ "/oit:roadm-path-impairments-set"
+ "/oit:roadm-path-impairments-set-id";
}
config false;
description
"Pointer to optical impairments of the associated ROADM
path.";
}
list llc-transceiver {
key "ttp-transponder-ref ttp-transceiver-ref";
config false;
description
"The list of transceivers having an LLC different from the
default LLC.";
leaf ttp-transponder-ref {
type leafref {
path "../../../../ttp-transceiver/transponder-ref";
}
description
"The reference to the transponder hosting the transceiver
of this LLCL entry.";
}
leaf ttp-transceiver-ref {
type leafref {
path "../../../../ttp-transceiver/transceiver-ref";
}
description
"The reference to the transceiver of this LLCL entry.";
}
leaf is-allowed {
type boolean;
description
"'true' - connectivity from this transceiver is allowed;
'false' - connectivity from this transceiver is
disallowed.";
}
leaf add-path-impairments-set {
type leafref {
path "../../../../../../../oit:templates"
+ "/oit:roadm-path-impairments-sets"
+ "/oit:roadm-path-impairments-set"
+ "/oit:roadm-path-impairments-set-id";
}
description
"Pointer to optical impairments of the associated ROADM
path.";
}
leaf drop-path-impairments-set {
type leafref {
path "../../../../../../../oit:templates"
+ "/oit:roadm-path-impairments-sets"
+ "/oit:roadm-path-impairments-set"
+ "/oit:roadm-path-impairments-set-id";
}
description
"Pointer to optical impairments of the associated ROADM
path.";
}
}
list additional-ltp {
when "derived-from-or-self(../../../tet:protection-type,"
+ "'oit:otsi-protection')" {
description
"This list applies only to TTPs that support individual
OTSi(G) protection.";
}
key "ltp-ref";
config false;
description
"The restricted list of the potential secondary LTPs that
can be selected when the LTP associated with this LLCP
entry is selected as a working LTP.
If this list is empty, all the other LTPs that can be
reached by this TTP can be selected as secondary LTPs.";
leaf ltp-ref {
type leafref {
path "../../../../../../nt:termination-point/nt:tp-id";
}
description
"The reference to potential secondary LTP that can be
selected when the LTP associated with this LLCP entry is
selected as a working LTP.";
}
leaf add-path-impairments-set {
type leafref {
path "../../../../../../../oit:templates"
+ "/oit:roadm-path-impairments-sets"
+ "/oit:roadm-path-impairments-set"
+ "/oit:roadm-path-impairments-set-id";
}
description
"Pointer to optical impairments of the associated ROADM
path.";
}
leaf drop-path-impairments-set {
type leafref {
path "../../../../../../../oit:templates"
+ "/oit:roadm-path-impairments-sets"
+ "/oit:roadm-path-impairments-set"
+ "/oit:roadm-path-impairments-set-id";
}
description
"Pointer to optical impairments of the associated ROADM
path.";
}
}
} // augmentation local-link-connectivity
}
]]>
As indicated in , section 4.1, "When a
network is of a certain type, it will contain a corresponding data
node. Network types SHOULD always be represented using presence
containers". The YANG model is in fact augmenting
"nw:network-types/tet:te-topology" with the new presence container
"optical-impairment-topology" representing an impairment-aware
topology type.
As described in , the OTSi signals in the YANG
model are described by augmenting the "nw:network" data node and
each OTSi signal is uniquely identified by its otsi-carrier-id,
which is unique within the scope the OTSiG the OTSi belongs to.
As described in , all OTSiGs are described
in the YANG model by augmenting the "nw:network" data node and each
OTSiG is uniquely identified by its otsi-group-id, which is unique
within the network. Each OTSiG also contains a list of the OTSi
signals belonging to the OTSiG.
Any OTSi signal is terminated by a transceiver and that is modeled
as a function of the tunnel termination point (TTP) and a
"ttp-transceiver" list of transceivers augmenting the
"tunnel-termination-point".
The relationship between OTSi and the related transceiver is
provided in the YANG model by the containers "incoming-otsi" for the
OTSi received by the transceiver's receiver and "outgoing-otsi" for
the OTSi generated by the transceiver's transmitter.
As described in , transponders are usually
used to terminate a layer 0 tunnel. But, they also can be used to
regenerate the signal and form a 3R regenarator. No new entity is
needed in the model since 3R functionality is provided by an optical
transponder pair. The YANG model provides two attributes related to
3R regenerators: "supported-termination-type" and
"supported-3r-mode".
supported-termination-type is describing if an optical transponder
is supporting tunnel termination only, or 3R regenerator only, or
both.
supported-3r-mode gives the configuration of transponder pair
providing the 3R functionality, if back-to-back (see
) or
Cross-3R (see ).
The model also provides a "regen-group" list and each list entry
represents a group of transponders that support the 3R
functionality. "transponder-ref" is pointing to the transponders
belonging to any specific group.
The data node "inter-layer-sequence-number" augments the termination
point attribute to describe additional constraints between a client
layer Link Termination Point (LTP), e.g., a muxponder port and a
server layer LTP.
To improve scalability, the model is defining templates for both,
"roadm-path-impairments-set", the list of the set of optical
impairments related to ROADM paths (express, add and drop paths) and
"explicit-transceiver-mode",the list of optical parameters related
to a transceiver's explicit mode providing the capability attributes
and optical impairment limits of an explicit transceiver mode.
These templates are also defined as "network" augmentation.
As stated in , the model defines three
types of approaches to describes the transceiver capabilities
(called "modes"):
Standard ModesOrganizational ModesExplicit Modes
These different modes (described in ,
, and
) are defined under the "transponders"
presence container augmenting the data node "node" as defined in
. If present, this container will indicate
that the set of transponders/transceivers in a node is described
with all the impairments attribute depending on the supported mode
type of any specific transponder. The YANG model permits to describe
the transponder capabilities in a mixed way (a transceiver can
support more than one mode out of the three mode types).
followed by , and
describe the OMS MCG and the OTS MCG
and the model represents this entity as a WDM TE-link
interconnecting two WDM-TE-nodes. The model augments the
te-link-attributes defined in with the
optical impairments for the WDM TE-link of the layer-0 topology
related to a specific network controller domain.
As described in detail in , the optical
impairments imposed by passive or active optical ROADM components
for the three different ROADM path types have to be taken into
account when an OTSi signal crosses a ROADM node.
The following two entities defined in are
used to describe the optical impairments for the 3 MC path types:
"connectivity-matrix" for express paths and
"local-link-connectivity-list" for Add/Drop paths crossing the
ROADM.
A list of optical impairment sets "roadm-path-impairments-set" is
defined under "templates", and this parameter set list entries will
contain the optical impairments for express, add, and drop paths.
The connectivity-matrix is augmented with the optical impairment
sets for the ROADM's express-path contained in the
"roadm-path-impairments-set", while the LLCL is augmented with the
optical impairment sets contained in the
"roadm-path-impairments-set" for the ROADM's add-path and drop-path
by using leafref "add-path-impairments-set" and leafref
"drop-path-impairments-set".
In case OTSi protection is supported, a list of additional line LTPs
is defined in the model to represent potential connectivity between
an add-drop LTP/TTP and multiple line LTPs including the related
optical impairments. See for
more details).
Additional OTSi protection architectures are described in detail in
and
.
This section is based on the template in Section 3.7 of
.
The "ietf-optical-impairment-topology" YANG module defines a data
model that is designed to be accessed via YANG-based management
protocols, such as NETCONF and RESTCONF
. These YANG-based management protocols
have to use a secure transport layer (e.g., SSH
, TLS , and QUIC
and
have to use mutual authentication.
The Network Configuration Access Control Model (NACM)
provides the means to restrict access for
particular NETCONF or RESTCONF users to a preconfigured subset of
all available NETCONF or RESTCONF protocol operations and content.
There are no particularly sensitive readable data nodes.
This YANG module uses groupings from other YANG modules that define
nodes that may be considered sensitive or vulnerable in network
environments. Refer to the Security Considerations of
for information as to
which nodes may be considered sensitive or vulnerable in network
environments.
Finally, the YANG module described in this document augments the
"ietf-network" YANG module and the
"ietf-te-topology" YANG module by adding
data nodes. The security considerations for the subtrees described
in those RFCs apply equally to the new data nodes that this module
adds.
This document registers the following namespace URIs in the IETF XML
registry :
This document registers the following YANG module in the YANG
Module Names registry :
We thank Daniele Ceccarelli and Oscar G. De Dios for useful
discussions and motivation for this work.
Physical transfer functions of optical network elements
Spectral grids for WDM applications: DWDM frequency grid
Amplified multichannel dense wavelength division multiplexing
applications with single channel optical interfaces
Generic functional architecture of the optical media network
Generic functional architecture of the optical media network
Amendment 1Optical transport network physical layer interfacesCharacteristics of multi-degree reconfigurable optical
add/drop multiplexersOptical transport network: Linear protection Amendment 1
Interfaces for the Optical Transport Network (OTN)Architecture of optical transport networksTypes and characteristics of optical transport network
equipmentOptical transport network: Linear protectionOpenROADM Multi-Source Agreement (MSA) - http://openroadm.org
A framework for analyzing in-band crosstalk accumulation in
ROADM-based optical networksYANG Model Tree Structure
../../../transponders/transponder/transponder-id
augment /nw:networks/nw:network/nt:link/tet:te
/tet:te-link-attributes:
+--ro oms-attributes
+--ro generalized-snr? l0-types:snr
+--ro equalization-mode? identityref
+--ro power-param
| +--ro nominal-carrier-power?
| | l0-types:power-dbm-or-unknown
| +--ro nominal-psd? l0-types:psd-or-unknown
+--ro media-channel-groups!
| +--ro media-channel-group* [otsi-group-ref]
| +--ro otsi-group-ref leafref
| +--ro media-channel* [media-channel-id]
| +--ro media-channel-id int16
| +--ro flexi-n? flexi-n
| +--ro flexi-m? flexi-m
| +--ro otsi-ref* [carrier-ref]
| | +--ro carrier-ref leafref
| | +--ro e2e-mc-path-ref* leafref
| +--ro delta-power?
| l0-types:power-ratio-or-unknown
+--ro oms-elements!
+--ro oms-element* [elt-index]
+--ro elt-index uint16
+--ro oms-element-uid? union
+--ro reverse-element-ref
| +--ro link-ref?
| | -> ../../../../../../../../nt:link/link-id
| +--ro oms-element-ref* leafref
+--ro (element)
+--:(amplifier)
| +--ro geolocation
| | +--ro altitude? int64
| | +--ro latitude? geographic-coordinate-degree
| | +--ro longitude? geographic-coordinate-degree
| +--ro amplifier
| +--ro type-variety string
| +--ro operational
| +--ro amplifier-element*
| [frequency-range-id stage-order]
| +--ro frequency-range-id
| | uint16
| +--ro frequency-range
| | +--ro lower-frequency frequency-thz
| | +--ro upper-frequency frequency-thz
| +--ro stage-order
| | uint8
| +--ro name?
| | string
| +--ro type-variety?
| | string
| +--ro power-param
| | +--ro (power-param)
| | +--:(channel-power)
| | | +--ro nominal-carrier-power
| | | l0-types:power-dbm-or-u\
nknown
| | +--:(power-spectral-density)
| | +--ro nominal-psd
| | l0-types:psd-or-unknown
| +--ro pdl?
| | l0-types:power-loss-or-unknown
| +--ro (amplifier-element-type)
| +--:(optical-amplifier)
| | +--ro optical-amplifier
| | +--ro actual-gain
| | | l0-types:power-gain-or-\
unknown
| | +--ro in-voa?
| | | l0-types:power-loss-or-\
unknown
| | +--ro out-voa?
| | | l0-types:power-loss-or-\
unknown
| | +--ro tilt-target
| | | l0-types:decimal-2-or-u\
nknown
| | +--ro total-output-power
| | | l0-types:power-dbm-or-u\
nknown
| | +--ro raman-direction?
| | | enumeration
| | +--ro raman-pump* [pump-id]
| | +--ro pump-id uint16
| | +--ro frequency?
| | | l0-types:frequency-t\
hz
| | +--ro power?
| | l0-types:decimal-2-o\
r-unknown
| +--:(dynamic-gain-equalizer)
| +--ro dynamic-gain-equalizer!
| +--ro media-channel* [flexi-n]
| +--ro flexi-n flexi-n
| +--ro flexi-m flexi-m
| +--ro delta-power?
| l0-types:power-ratio\
-or-unknown
+--:(fiber)
| +--ro fiber
| +--ro type-variety string
| +--ro length
| | l0-types:decimal-2-or-unknown
| +--ro loss-coef
| | l0-types:decimal-2-or-unknown
| +--ro total-loss?
| | l0-types:power-loss-or-unknown
| +--ro pmd?
| | l0-types:decimal-2-or-unknown
| +--ro conn-in?
| | l0-types:power-loss-or-unknown
| +--ro conn-out?
| l0-types:power-loss-or-unknown
+--:(concentrated-loss)
+--ro concentrated-loss
+--ro loss l0-types:power-loss-or-unknown
augment /nw:networks/nw:network/nw:node/tet:te
/tet:tunnel-termination-point:
+--ro ttp-transceiver* [transponder-ref transceiver-ref]
+--ro transponder-ref
| -> ../../../../transponders/transponder/transponder-id
+--ro transceiver-ref leafref
augment /nw:networks/nw:network/nw:node/nt:termination-point:
+--ro protection-type? identityref
augment /nw:networks/nw:network/nw:node/nt:termination-point
/tet:te:
+--ro inter-layer-sequence-number? uint32
augment /nw:networks/nw:network/nw:node/tet:te
/tet:information-source-entry/tet:connectivity-matrices:
+--ro roadm-path-impairments-set? leafref
augment /nw:networks/nw:network/nw:node/tet:te
/tet:information-source-entry/tet:connectivity-matrices
/tet:connectivity-matrix:
+--ro roadm-path-impairments-set? leafref
augment /nw:networks/nw:network/nw:node/tet:te
/tet:te-node-attributes/tet:connectivity-matrices:
+--ro roadm-path-impairments-set? leafref
augment /nw:networks/nw:network/nw:node/tet:te
/tet:te-node-attributes/tet:connectivity-matrices
/tet:connectivity-matrix:
+--ro roadm-path-impairments-set? leafref
augment /nw:networks/nw:network/nw:node/tet:te
/tet:te-node-attributes/tet:connectivity-matrices
/tet:connectivity-matrix/tet:from:
+--ro additional-ltp* [ltp-ref]
+--ro ltp-ref
| -> ../../../../../../../nt:termination-point/tp-id
+--ro roadm-path-impairments-set? leafref
augment /nw:networks/nw:network/nw:node/tet:te
/tet:te-node-attributes/tet:connectivity-matrices
/tet:connectivity-matrix/tet:to:
+--ro additional-ltp* [ltp-ref]
+--ro ltp-ref
| -> ../../../../../../../nt:termination-point/tp-id
+--ro roadm-path-impairments-set? leafref
augment /nw:networks/nw:network/nw:node/tet:te
/tet:tunnel-termination-point
/tet:local-link-connectivities:
+--ro add-path-impairments-set? leafref
+--ro drop-path-impairments-set? leafref
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-set? leafref
+--ro drop-path-impairments-set? leafref
+--ro llc-transceiver* [ttp-transponder-ref ttp-transceiver-ref]
| +--ro ttp-transponder-ref
| | -> ../../../../ttp-transceiver/transponder-ref
| +--ro ttp-transceiver-ref
| | -> ../../../../ttp-transceiver/transceiver-ref
| +--ro is-allowed? boolean
| +--ro add-path-impairments-set? leafref
| +--ro drop-path-impairments-set? leafref
+--ro additional-ltp* [ltp-ref]
+--ro ltp-ref
| -> ../../../../../../nt:termination-point/tp-id
+--ro add-path-impairments-set? leafref
+--ro drop-path-impairments-set? leafref
]]>
JSON Code Examples for Optical Protection Uses Cases
JSON example for use case in
with full and with restricted
connectivity:
The JSON example below addresses the optical protection use case
for TTPs associated with local optical transponders (integrated
WDM-TE-node):
where full connectivity exists between the ROADM add-drop ports
and the ROADM ports for the different ROADM degrees illustrated
in below.
where restricted connectivity exists between the ROADM add-drop
ports and the ROADM ports for the different ROADM degrees
illustrated in below.
Note that and
illustrate the connectivity for a
single TTP only, i.e., the figures are not showing TTP-1, TTP-2,
TTP-3, and TTP-4, which are used in the JSON code example below.
The connectivity is reflected in the local-link-connectivities
between the TTP associated with the transceiver of the local OT
and the LTPs that can be reached including the optical impairments
for the different paths.
o- / | /----o | LTP 1|
| | +----| | / | | \ | o------/ | 1 o------o->
--o->| | Tx o-->o--o 5 | | \ | | -o | | |
| | +----| | \ | AD2 --o 4 o-\ / |___/ | |
<-o--| | Rx o | ---o-->o- | | \ / DEG1| |
| | +----| +-------+ | \ | o- \ / ___ | |
| | | | | \___| \ \ / | \ Line |
| +-------+ internal | | \ \------o | LTP 2|
| AD ports | | \ / | 2 o------o->
| | | ___ \ /---o | | |
| o | / | / \ / |___/ | |
| | | | o--/ \ DEG2| |
| | \ | | / \ ___ | |
| | -o 6 o----/ \ | \ Line |
| | | | \--o | LTP 3|
| | | o----\ | 3 o------o->
| o \___| \------o | | |
| | |___/ | |
| | DEG3| |
| +--------------------------------+ |
+--------------------------------------------------------------+
]]> o-- / | /---o | LTP 1|
| | +----| | / | | \ | o------/ | 1 o------o->
--o->| | Tx o-->o--o 5 | | ---o 4 | /-o | | |
| | +----| | \ | AD2 | o-\ / |___/ | |
<-o--| | Rx o | ---o-->o-- \___| \ / DEG1| |
| | +----| +-------+ | \ ___ \ | ___ | |
| | | | \ / | \ | | \ Line |
| +-------+ internal | \ | o-------/ o | LTP 2|
| AD ports | -o 6 | \ | 2 o------o->
| | | o-------\---o | | |
| o \___| | |___/ | |
| | | DEG2| |
| | | ___ | |
| | | | \ Line |
| | \--o | LTP 3|
| | | 3 o------o->
| o o | | |
| | |___/ | |
| | DEG3| |
| +--------------------------------+ |
+--------------------------------------------------------------+
]]>
JSON example for use case in
with restricted connectivity:
The JSON example below addresses the optical protection use case
where the optical transponder is not part of the WDM-TE-node
containing the ROADM function (WDM-TE-node-2) but is part of a
separate WDM-TE-node (WDM-TE-node-1) containing one or more optical
transponders (remote OTs).
As described in , a TE-link
interconnects the remote OT with an add-drop port of WDM-TE-node-2.
This is illustrated in .
In this use case, the connectivity is reflected in the
connectivity-matrix describing the connectivity between the LTPs
representing an add-drop port in WDM-TE-node-2 connected to the
transceiver of a remote OT and the LTPs associated with the
different ROADM degrees including the optical impairments for the
different paths.
--o->| Tx o---o->o--o 5 | \--o | -o | |
| +----| | | \ | | 4 | / |___/ |
<-o--| Rx o | | ---o-\ /--o | / DEG 1|
| +----| | +-------+ \ | | o- / ___ |
| | | Splitter \ | \___| \ / | \ Line |
| | | +-------+ | | \ o | LTP 2|
| TTP2| | | ---o---|--/ \ / | 2 o------o->
| +----| | | / | | ___ \ /---o | |
--o->| Tx o---o->o--o 5 | \ / | / \ / |___/ |
| +----| | | \ | \ | o--/ \ DEG 2 |
<-o--| Rx o | | ---o--\ \--o | / \ ___ |
| +----| | +-------+ \ | | / \ | \ Line |
| | | LTP 30 \----o 6 | / \--o | LTP 3|
| TTP3| | | o--/ | 3 o------o->
| +----| | /-------->o | o | |
--o->| Tx o---o---------/ | | |___/ |
| +----| | LTP 40 \___| DEG 3 |
<-o--| Rx o | AD 2 |
| +----| | |
| | | |
+-------+ | |
| |
+--------------------------------------------------+
]]> Optical Transponders in a Remote Shelf (Remote OTs) illustrates a configuration where
the optical transponders and the ROADM are located in a different
WDM-TE-nodes.
| | Tx o---------->o---->o | LTP 1 |
| | OT 1 +----| | | o-------o<--->
<-o---| | Rx o<----------o<----o | |
| | +----| | AD | | |
| | | | LTP | | |
| +------------+ | | | |
| | | | | Line |
| +------------+ | | | LTP 2 |
| | | | AD | o-------o<--->
| | +----| | LTPs| | |
--o-->| | Tx o---------->o---->o | |
| | +----| | | | |
<-o---| | Rx o<----------o<----o | |
| | OT 2 +----| | | | Line |
--o-->| | Tx o---------->o---->o | LTP 3 |
| | +----| | | o-------o<--->
<-o---| | Rx o<----------o<----o | |
| | +----| | | | |
| | | | | | |
| +------------+ | +------------+ |
| | | |
+----------------+ +--------------------------+
]]>
As described in , the external shelf can
be modeled as WDM-TE-node with termination capability only (not
switching) and the add/drop link between a remote optical
transceiver and a ROADM add/drop port can be modeled as a WDM
TE-link with the same optical impairments as those defined for a
WDM TE-link between WDM-TE-nodes (OMS MCG).
If the two WDM-TE-nodes are reported in different network topology
instances, the plug-id attribute, defined in
, can be used to discover the adjacency for
add/drop TE-links.
It is worth noting that there are no standard protocols for
automatic discovery of the adjacency between an external transceiver
and a ROADM add/drop port and therefore the information reported in
the plug-id can be either statically configured or provided through
vendor-specific discovery mechanisms.
Each add/drop TE-link carries a single OTSi between the transceiver
and ROADM add/drop port and one or more OTSis in the reverse
direction (between the ROADM add/drop and the transceiver).
Depending on control architecture (e.g., when the two WDM-TE-nodes
are reported in different network topology instances by different
controllers), the controller reporting the WDM-TE-node, abstracting
the external OT shelf, may be not able to provide the information
about the end-to-end MC configuration (i.e.,flexi-n and flexi-m)
nor of all the received OTSis, within the end-to-end MC, besides the
configured incoming OTSi, since the end-to-end MC configuration
depends on how the ROADM network is configured and the remote OT
shelf is not aware of that.
In this case only the incoming-otsi and outgoing-otsi can be
reported within an end-to-end MC with an unspecified frequency-slot
(i.e., without reporting flexi-n and flexi-m configuration of the
end-to-end MC).
When an OTSiG has more than one OTSi, its OTSis are carried by
different parallel add/drop TE-links. In order to represent the fact
that these OTSis are co-routed, the add/drop TE-links are bundled
together in a bundled add/drop TE-link. The finest granularity for
the bundled add/drop TE-link is the set of all the add/drop TE-links
terminating on the same OT.
For example, in , it is possible
to define two bundled add/drop TE-links, one for OT1 and one for OT2
or just one add/drop TE-link both OTs.
The model for a bundled add/drop TE-link and the relationship with
its component TE-links is already defined in the bundled-links
container of .
In the general case, the optical impairments and connectivity
constraints are reported for each add/drop TE-link and therefore no
optical impairments are reported in the bundled add/drop TE-link
that is used just to model the co-routing aspects of the OTSis
belonging to the same OTSiG.
The per-transceiver Local Link Connectivity (LLC) is used in the
WDM-TE-node which abstracts the remote OT shelf (e.g., WDM-TE-node-1
in ), to represent the association
between each transceiver and each LTP terminating the add/drop
TE-link which models the transceiver port.
The connectivity matrix in the WDM-TE-node which abstract the edge
ROADM (e.g., WDM-TE-node-2 in )
references the LTPs terminating the add/drop TE-links which models
the ROADM add/drop ports.
JSON Examples for Optical Transponders in a Remote Shelf
(Remote OTs)
The JSON example below describes a topology where the optical
transponders are located in a remote WDM-TE-node as depicted in
).
Line-folding as defined in has been used
for the JSON code example below.
ContributorsThanks to all contributors.Huawei Technologiesaguo@futurewei.comSmartopticsjonas.martensson@smartoptics.comSamsung Electronicsyounglee.tx@gmail.comHuawei Technologieszhenghaomian@huawei.comScuola Superiore Sant'Annanicosambo@gmail.comCiscogiomarti@cisco.comOrangejeanluc.auge@orange.comOrangejulien.meuric@orange.comNokiaVictor.Lopez@nokia.comNokiaEnrico.Griseri@nokia.comJuniperggrammel@juniper.netCiscormanzott@cisco.com