A YANG Data Model for Optical Impairment-aware Topology

A YANG Data Model for Optical Impairment-aware Topology Nokia

Dieter.Beller@nokia.com

Orange

esther.lerouzic@orange.com

Nokia

Sergio.Belotti@nokia.com

Cisco

ggalimbe@cisco.com

Huawei Technologies

Italo.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 WSON, while it is known as Impairment-Aware Routing and Spectrum Assigment (IA-RSA) for SSON. This document provides a YANG data model for the impairment-aware TE topology in optical networks.

In order to provision an optical connection (an optical path) through a wavelength switched optical networks (WSONs) 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. 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, which can be utilized by a Multi-Domain Service Coordinator (MDSC) to collect states of WSON impairment data from the Transport 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 . Similarly,this model can also be exported by the MDSC to a Customer Network Controller (CNC), which can run an offline planning process to map latter the services in the network. It is worth noting that optical data plane interoperability is a complex topic especially in a multi vendor environment and usually requires joint engineering, which is independent from control plane and management plane capabilities. The YANG data model defined in this draft is providing sufficient information to enable optical impairment aware path computation. Optical data plane interoperability is outside the scope of this draft. This document augments the generic TE topology YANG model defined in where possible. This document defines one YANG module: ietf-optical-impairment- topology () according to the new Network Management Datastore Architecture .

Refer to , , and for the key terms used in this document. The following terms are defined in and are not redefined here: client server augment data model data node The following terms are defined in and are not redefined here: configuration data state data 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 may 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.

A simplified graphical representation of the data model is used in Section 2 of this 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 Reference optical-imp-topo ietf-optical-impairment-topology [RFCXXXX] layer0-types ietf-layer0-types l0-types-ext ietf-layer0-types-ext nw ietf-network nt ietf-network-topology tet ietf-te-topology [Editor's note: The RFC Editor will replace XXXX with the number assigned to the RFC once this draft becomes an RFC.]

shows the control plane architecture.

|| | || | +------------------------+ | | OPTICAL | +---------+ | | DOMAIN | +---------+ | Device | | | CONTROLLER | | Device | | config. | | +------------------------+ | config. | +---------+ v // || \\ +---------+ ______|______ // || \\ ______|______ / OT \ // || \\ / OT \ | +--------+ |// __--__ \\| +--------+ | | |Vend. A |--|----+ ( ) +----|--| Vend. A| | | +--------+ | | ~-( )-~ | | +--------+ | | +--------+ | +---/ \---+ | +--------+ | | |Vend. B |--|--+ / \ +--|--| Vend. B| | | +--------+ | +---( OLS Segment )---+ | +--------+ | | +--------+ | +---( )---+ | +--------+ | | |Vend. C |--|--+ \ / +--|--| Vend. C| | | +--------+ | +---\ /---+ | +--------+ | | +--------+ | | ~-( )-~ | | +--------+ | | |Vend. D |--|----+ (__ __) +----|--| Vend. D| | | +--------+ | -- | +--------+ | \_____________/ \_____________/ ^ ^ | | | | Scope of [I-D.ietf-ccamp-dwdm-if-param-yang] ]]> The topology model developed in this document is an abstracted topology YANG model that can be used at the interfaces between the MDSC and the Optical Domain Controller (aka MPI) and between the Optical Domain Controller and the Optical Device (aka SBI) in . It is not intended to support a detailed low-level DWDM interface model. DWDM interface model is supported by the models presented in .

This section provides the description of the optical transport network reference architecture and its relevant components to support optical 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 ]]> BA (on the left side WDM-TE-node) is the engress Amplifier and PA (on the right side WDM-TE-node is the ingress amplifier for the OMS Media Channel Group (MCG) .

According to and , an OTS Media Channel Group (MCG) represents a topological construct between two adjacent amplifiers, such as:

According to and , an OMS Media Channel Group (MCG) represents a topological construct between two WDM-TE-nodes. Specifically, it originates at the ROADM in the source WDM-TE-node and terminates at the ROADM in the destination WDM-TE-node including the Booster Amplifier (BA) and the Pre-Amplifier (PA) in the WDM-TE-nodes as well as the In-Line Amplifiers (ILAs) between the two WDM-TE-nodes. An OMS MCG can be decomposed into a sequence of OTS MCGs and amplifiers. An OMS MCG can be described as a sequence of elements such as BA, fiber section, ILA, PA, and concentrated loss wherever there is an insertion loss caused for example by a fiber connector. 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 no switching capabilities. An OMS MCG is terminated on both ends by a link termination point (LTP) as defined in . Links in optical transport networks are typically bidirectional but have to be modeled as a pair of two unidirectional 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 . The YANG model defined below 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 an 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 optical impairment-aware topology YANG model below defines the OTSi properties needed for optical 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 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 the OTSi's is described in , section 10.2. The YANG model below 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. The MC is an end-to-end topological network construct and can be considered as an "optical pipe" with a well-defined frequency slot between one or more optical transmitters each generating an OTSi and the corresponding optical receivers terminating the OTSi's. If the MC carries more than one OTSi, it is assumed that these OTSi's belong to the same OTSiG.

]]> 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 end-to-end 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.

The definition of the MCG is currently work in progress in ITU-T and is defined in section 7.1.3 of the new ITU-T draft Recommendation G.807 (still work in progress) [G.807]. The YANG model below assumes that the MCG is a logical grouping of one or more MCs that are used to 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 have to 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 have to be co-routed, i.e., have to 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. There are three main optical amplifier technologies: 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, 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 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 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. One modeling consideration of the ROADM internal is to model power parameter through the ROADM, factoring the output power from the Pre-Amplifier minus the ROADM power loss would give the input power to the Booster Amplifier. In other words, Power_in (@ ROADM Booster) = Power_out (@ ROADM Pre-Amplifier) - Power_loss (@ ROADM WSS/Filter).

[Editor's note: The relationship between the transponder and the OTSi in the YANG model described in needs further clarification and refinement.] A Transponder is the element that sends and receives the optical signal from a DWDM network. A transponder can comprise one or more transceiver modules. A transceiver represents a transmitter/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 like for example aggregation (multiplexing) of client layer signals, which is outside the scope of this document addressing 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 . Due to the fact that optical transport services (TE tunnels) are typically bidirectional, a TTP is also modeled as a bidirectional entity like the LTP described above. 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 may be associated with multiple transceiver modules. A transponder is typically characterized by its data/symbol rate and the maximum distance the signal can travel. Other transponder properties are: carrier frequency for the optical channels, output power per channel, measured input power, modulation scheme, 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 Modes Organizational Modes Explicit Modes

A standard mode is related to an optical specification developed by an SDO organization. Currently, the "Standard Modes" can only be referred to ITU-T G.698.2 since G.698.2 is the only specification defining "Standard Modes" today. Nothing is precluding, however, to consider other specifications provided by any other SDO in the Standard Mode context as soon as such sepcifications will be available. An application code as defined in ITU-T G.698.2 is representing a standard ITU-T G.698.2 optical interface specification towards the realization of transversely compatible DWDM systems. 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.

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 anoperational mode and are therefore not defined in the YANG model. Examples of these properties are: FEC type Modulation scheme Encoding (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 shall 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 shall, however, only be an done in exceptional cases and shall 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 to encode, explicitly, 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 draft. 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 configured Current 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 above (choice in the YANG model). The YANG model allows to describe 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 transmitter tunability describing the transmitter's frequency fine tuning steps (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 OSNR, max PMD, max CD, max PDL, Q-factor limit, are explicitly defined for the explicit modes while they are defined implicitly for the application codes and organizational modes. 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 "supported-mode" 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 OTSi Pointer to the transceiver instance terminating the OTSi Pointer to the currently configured transceiver mode Additionally, the OTSi is described by the following frequency and optical power related attributes: current carrier-frequency currently transmitted channel power currently received channel power currently 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 regeneartion 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 provided functionality, 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 above. 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 an uni-directional mode. Implemantations may support the change of the carrier frequency where the receiver may operate at a different optical frequency as 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 regenaretor realised by two transceivers operated in the uni-directional mode.

| Receiver |---|Sig. --+ | | |-------------+ | | | | <---| Transmitter |---|Proc.<-+ | | |-------------+ +---------+ | | | +-----------------------------+ 3R in forward direction Optical Transponder 2 +-----------------------------+ | Transceiver | |-------------+ +---------+ | --->| Receiver |---|Sig. --+ | | |-------------+ | | | | <---| Transmitter |---|Proc.<-+ | | |-------------+ +---------+ | | | +-----------------------------+ 3R in reverse direction Sig. Proc. = Signal Processing ]]> Due to the fact that 3R regenerators are composed of an optical transponder pair, the capabilitiy whether an optical transponder can be used as a 3R regenerator is is added to the transponder capabilities. Hence, no additional entity is required for describing 3R regenerators in the TE-topology YANG model. The optical transonder capabilities regarding the 3R regenerator function are described by the following two YANG model attributes: supported-termination-type supported-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 attrbute describes the configuration of the transponder pair forming the 3R regeneartor as described above. More text to be added here!

WSS separates the incoming light input spectrally as well as spatially, then chooses the wavelength that is of interest by deflecting it from the original optical path and then couple it to another optical fibre port. WSS/Filter is internal to ROADM. So this document does not model the inside of ROADM.

There are various optical fiber types defined by ITU-T. There are several fiber-level parameters that need to be factored in, such as, fiber-type, length, loss coefficient, pmd, connectors (in/out). 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 including optical impairments for DWDM networks defined below intend 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-node 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 collocated (short fiber links not imposing any significant optical impairments). The different WDM-node architectures are briefly described and illustrated in the following subsections. [Editor's note: The modeling of remote optical transponders located for example in the client device with a single channel link between the OT and the add/drop port of the WDM-TE-node requires further investigations and will be addressed in a future revision of this document.]

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 above). 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 collocated 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 [Editor's note: this requires further study].

Recently, some DWDM network operators started 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 subsystems Add/drop subsystems Optical 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.

[Editor's note: the following text still needs to be updated based on the agreed terminology] 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-talk Filtering effects (for further study) A ROADM node contains a wavelength selective photonic switching function (WSS)that is capable of switching 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, this is a single channel signal (single OTSi), but principally this could also be a group of OTSi signals. The optical impairments associated with these MCs are different and the paths of the MCs inside the ROADM node can be categorized as follows: 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 ROADM Drop 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 have to be modeled separately. The optical impairments associated with each of the three types of ROADM-node-internal paths described above are modeled as optical impairment parameter sets. These parameter sets are modeled as an augmentation of the te-node-attributes defined in . The te-node-attributes are augmented with a list of roadm-path-impairments for the three ROADM path types distinguished by the impairment-type. Each roadm-path-impairments list entry contains the set of optical impairment parameters for one of the three path types indicated by the impairment-type. For the optical feasibility calculation based on the optical impairments, it is necessary to know whether the optical power of the OTSi stays within a certain power window. This is reflected by some optical power related parameters such as loss parameters or power parameters, which are included in the optical impairment parameter sets (see tree view in ). 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). [Editor's note: this section is still work in progress]

The YANG model defined in this document supports the following protection architectures: Individual OTSi protection OMS MCG protection = TE-link protection between adjacent WDM-TE-nodes [Editor's note: this section is still work in progress]

Individual OTSi protection is a protection architecture where an individual OTSi signal is protected as defined in Appendix III of ITU-T Recommendation G.873.1 . This protection architecture requires dedicated photonic protection functions that are typically provided by dedicated protection hardware. These photonic protection functions are a photonic splitter function splitting the OTSi signal in transmit direction and a photonic selector function selecting the OTSi signal in receive direction from one of the two protection legs between the 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). In case of individual OTSi protection, there are two network media channel paths associated with the OTSi signal. In the YANG model, this is modeled as a leaf list of the otsi providing the nmc-path-id for the two network media channel paths associated with the individually protected otsi. [Editor's note: this section is still work in progress]

OMS MCG protection is a protection architecture where a TE-link between two adjacent WDM-TE-nodes is protected. This is a local protection scheme, which can be modeled as a TE-link property. [Editor's note: this section is still work in progress]

[Editor's note: tree view below always has to be updated before submitting a new revision!]

[Editor's note: YANG code below always has to be updated before submitting a new revision!]

module ietf-optical-impairment-topology { yang-version 1.1; namespace "urn:ietf:params:xml" + ":ns:yang:ietf-optical-impairment-topology"; prefix "optical-imp-topo"; import ietf-network { prefix "nw"; } import ietf-network-topology { prefix "nt"; } import ietf-te-topology { prefix "tet"; } import ietf-layer0-types { prefix "l0-types"; } organization "IETF CCAMP Working Group"; contact "WG Web: WG List: Editor: Young Lee Editor: Haomian Zheng Editor: Nicola Sambo Editor: Victor Lopez Editor: Gabriele Galimberti Editor: Giovanni Martinelli Editor: Jean-Luc Auge Editor: Le Rouzic Esther Editor: Julien Meuric Editor: Italo Busi Editor: Dieter Beller Editor: Sergio Belotti Editor: Griseri Enrico Editor: Gert Grammel "; description "This module contains a collection of YANG definitions for impairment-aware optical networks. Within this module, if the value of a mandatory attribute is unknown, it MUST be reported using the empty type. If an optional attribute is applicable but its value is unknown, it MUST be reported using the empty type. If an optional attribute is not applicable to an entity, it MUST be omitted (not be present in the datastore). 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. Copyright (c) 2022 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). 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 2022-07-06 { description "Initial Version"; reference "RFC XXXX: A Yang Data Model for Impairment-aware Optical Networks"; } // grouping grouping sliceable-transponder-attributes { description "Configuration of a sliceable transponder."; list sliceable-transponder-list { key "carrier-id"; config false; description "List of carriers"; leaf carrier-id { type uint32; config false; description "Identifier of the carrier"; } } } /* * Groupings */ grouping amplifier-params { description "describes parameters for an amplifier"; container amplifier { description "amplifier type, operatonal parameters are described."; leaf type-variety { type string; mandatory true ; description "String identifier of amplifier type referencing a specification in a separate equipment catalog"; } container operational { description "amplifier operational parameters"; list amplifier-element { description "The list of parallel amplifier elements within an amplifier used to amplify different frequency ranges."; leaf name { type string; description "The name of the amplifier element as specified in the vendor's specification associated with the type-variety."; } container frequency-range { description "The frequency range amplified by the amplifier element."; uses l0-types:frequency-range; } leaf actual-gain { type l0-types:power-in-db-or-null; mandatory true ; description ".."; } leaf tilt-target { type l0-types:decimal-2-digits-or-null; mandatory true ; description "The tilt target defined between lower and upper frequency of the amplifier frequency range."; } leaf out-voa { type l0-types:power-in-db-or-null; units dB; mandatory true; description ".."; } leaf in-voa { type l0-types:power-in-db-or-null; mandatory true; description ".."; } leaf total-output-power { type l0-types:power-in-db-or-null; mandatory true; description "It represent 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."; } uses power-param; 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 { description "The list of pumps for the Raman amplifier."; leaf frequency { type l0-types:frequency-thz; description "The raman pump central frequency."; } leaf power { type l0-types:decimal-2-digits-or-null; units "Watts"; description "The total pump power considering a depolarized pump at the raman pump central frequency."; } } } // 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"; leaf type-variety { type string ; mandatory true ; description "fiber type"; } leaf length { type l0-types:decimal-2-digits-or-null; units km; mandatory true ; description "length of fiber"; } leaf loss-coef { type l0-types:decimal-2-digits-or-null; units dB/km; mandatory true ; description "loss coefficient of the fiber"; } leaf total-loss { type l0-types:power-in-db-or-null; mandatory true ; description "includes all losses: fiber loss and conn-in and conn-out losses"; } leaf pmd{ type l0-types:decimal-2-digits-or-null; units sqrt(ps); description "pmd of the fiber"; } leaf conn-in{ type l0-types:power-in-db-or-null; description "connector-in"; } leaf conn-out{ type l0-types:power-in-db-or-null; description "connector-out"; } } } grouping roadm-express-path { description "The optical impairments of a ROADM express path."; leaf roadm-pmd { type union { type decimal64 { fraction-digits 8; range "0..max"; } type empty; } units "ps/(km)^0.5"; description "Polarization Mode Dispersion"; } leaf roadm-cd { type union { type decimal64 { fraction-digits 5; } type empty; } units "ps/nm"; description "Chromatic Dispersion"; } leaf roadm-pdl { type l0-types:power-in-db-or-null; description "Polarization dependent loss"; } leaf roadm-inband-crosstalk { type l0-types:power-in-db-or-null; description "In-band crosstalk, or coherent crosstalk, can occur in components that can have multiple same wavelength inputs with the inputs either routed to different output ports, or all but 1 blocked"; } leaf roadm-maxloss { type l0-types:power-in-db-or-null; description "This is the maximum expected add path loss from the ROADM ingress to the ROADM egress assuming no additional add path loss is added"; } } grouping roadm-add-path { description "The optical impairments of a ROADM add path."; leaf roadm-pmd { type union { type decimal64 { fraction-digits 8; range "0..max"; } type empty; } units "ps"; description "Polarization Mode Dispersion"; } leaf roadm-cd { type union { type decimal64 { fraction-digits 5; } type empty; } units "ps/nm"; description "Cromatic Dispersion"; } leaf roadm-pdl { type l0-types:power-in-db-or-null; description "Polarization dependent loss"; } leaf roadm-inband-crosstalk { type l0-types:power-in-db-or-null; description "In-band crosstalk, or coherent crosstalk, can occur in components that can have multiple same wavelength inputs,with the inputs either routed to different output ports, or all but 1 blocked. In the case of add path it is the total of the add block + egress WSS crosstalk contributions."; } leaf roadm-maxloss { type l0-types:power-in-db-or-null; description "This is the maximum expected add path loss from the add/drop port input to the ROADM egress, assuming no additional add path loss is added. This is used to establish the minimum required transponder output power required to hit the ROADM egress target power levels and preventing to hit the WSS attenuation limits. If the add path contains an internal amplifier this loss value should be based on worst case expected amplifier gain due to ripple or gain uncertainty"; } leaf roadm-pmax { type l0-types:power-in-dbm-or-null; description "This is the maximum (per carrier) power level permitted at the add block input ports, that can be handled by the ROADM node. This may reflect either add amplifier power contraints or WSS adjustment limits. Higher power transponders would need to have their launch power reduced to this value or lower"; } leaf roadm-osnr { type l0-types:snr-or-null; description "Optical Signal-to-Noise Ratio (OSNR). If the add path contains the ability to adjust the carrier power levels into an add path amplifier (if present) to a target value, this reflects the OSNR contribution of the add amplifier assuming this target value is obtained. The worst case OSNR based on the input power and NF calculation method, and this value, should be used (if both are defined)."; } leaf roadm-noise-figure { type union { type decimal64 { fraction-digits 5; } type empty; } units "dB"; description "Noise Figure. If the add path contains an amplifier, this is the noise figure of that amplifier inferred to the add port. This permits add path OSNR calculation based on the input power levels to the add block without knowing the ROADM path losses to the add amplifier."; } } grouping roadm-drop-path { description "roadm drop block path optical impairments"; leaf roadm-pmd { type union { type decimal64 { fraction-digits 8; range "0..max"; } type empty; } units "ps/(km)^0.5"; description "Polarization Mode Dispersion"; } leaf roadm-cd { type union { type decimal64 { fraction-digits 5; } type empty; } units "ps/nm"; description "Chromatic Dispersion"; } leaf roadm-pdl { type l0-types:power-in-db-or-null; description "Polarization dependent loss"; } leaf roadm-inband-crosstalk { type l0-types:power-in-db-or-null; description "In-band crosstalk, or coherent crosstalk, can occur in components that can have multiple same wavelength inputs,with the inputs either routed to different output ports,or all but 1 blocked. In the case of drop path it is the total of the ingress to drop e.g. WSS and drop block crosstalk contributions."; } leaf roadm-maxloss { type l0-types:power-in-db-or-null; description "The net loss from the ROADM input,to the output of the drop block. If ROADM ingress to drop path includes an amplifier, the amplifier gain reduces the net loss. This is before any additional drop path attenuation that may be required due to drop amplifier power contraints. The max value correspond to worst case expected loss, including amplifier gain ripple or uncertainty. It is the maximum output power of the drop amplifier."; } leaf roadm-minloss { type l0-types:power-in-db-or-null; description "The net loss from the ROADM input, to the output of the drop block. If this ROADM ingress to drop path includes an amplifier,the amplifier gain reduces the net loss. This is before any additional drop path attenuation that may be required due to drop amplifier power contraints. The min value correspond to best case expected loss, including amplifier gain ripple or uncertainty."; } leaf roadm-typloss { type l0-types:power-in-db-or-null; description "The net loss from the ROADM input, to the output of the drop block. If this ROADM ingress to drop path includes an amplifier, the amplifier gain reduces the net loss. This is before any additional drop path attenuation that may be required due to drop amplifier power contraints. The typ value correspond to typical case expected loss."; } leaf roadm-pmin { type l0-types:power-in-dbm-or-null; description "If the drop path has additional loss that is added, for example, to hit target power levels into a drop path amplifier, or simply, to reduce the power of a strong carrier (due to ripple,for example), then the use of the ROADM input power levels and the above drop losses is not appropriate. This parameter corresponds to the min per carrier power levels expected at the output of the drop block. A detail example of the comparison using these parameters is detailed in section xxx of the document yyy."; } leaf roadm-pmax { type l0-types:power-in-dbm-or-null; description "If the drop path has additional loss that is added, for example, to hit target power levels into a drop path amplifier,or simply,to reduce the power of a strong carrier(due to ripple,for example), then the use of the ROADM input power levels and the above drop losses is not appropriate. This parameter corresponds to the best case per carrier power levels expected at the output of the drop block. A detail example of the comparison using these parameters is detailed in section xxx of the document yyy"; } leaf roadm-ptyp { type l0-types:power-in-dbm-or-null; 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-null; description "Optical Signal-to-Noise Ratio (OSNR). Expected OSNR contribution of the drop path amplifier(if present) for the case of additional drop path loss (before this amplifier) in order to hit a target power level (per carrier). If both, the OSNR based on the ROADM input power level (Pcarrier = Pref+10Log(carrier-baudrate/ref-baud) + delta-power) and the input inferred NF(NF.drop), and this OSNR value, are defined, the minimum value between these two should be used"; } leaf roadm-noise-figure { type union { type decimal64 { fraction-digits 5; } type empty; } units "dB"; description "Drop path Noise Figure. If the drop path contains an amplifier, this is the noise figure of that amplifier, inferred to the ROADM ingress port. This permits to determine amplifier OSNR contribution without having to specify the ROADM node’s losses to that amplifier. This applies for the case of no additional drop path loss, before the amplifier, in order to reduce the power of the carriers to a target value"; } } grouping concentratedloss-params{ description "concentrated loss"; container concentratedloss{ description "concentrated loss"; leaf loss { type l0-types:power-in-db-or-null; mandatory true; description ".."; } } } grouping power-param{ description "optical power or PSD after the ROADM or after the out-voa"; choice power-param { description "select the mode: channel power or power spectral density"; case channel-power { when "/nw:networks/nw:network/nt:link/tet:te /tet:te-link-attributes/OMS-attributes /equalization-mode='carrier-power'"; leaf nominal-carrier-power{ type l0-types:power-in-dbm-or-null; description " Reference channel power. Same grouping is used for the OMS power after the ROADM (input of the OMS) or after the out-voa of each amplifier. "; } } case power-spectral-density{ when "/nw:networks/nw:network/nt:link/tet:te /tet:te-link-attributes/OMS-attributes /equalization-mode='power-spectral-density'"; leaf nominal-power-spectral-density{ type union { type decimal64 { fraction-digits 16; } type empty; } units W/Hz ; description " Reference power spectral density after the ROADM or after the out-voa. Typical value : 3.9 E-14, resolution 0.1nW/MHz"; } } } } grouping oms-general-optical-params { description "OMS link optical parameters"; leaf generalized-snr { type l0-types:snr; description "generalized snr"; } leaf equalization-mode{ type identityref { base l0-types:type-power-mode; } mandatory true; description "equalization mode"; } uses power-param; } grouping otsi-group { description "OTSiG definition , representing client digital information stream supported by 1 or more OTSi"; list otsi { key "otsi-carrier-id"; config false; description "list of OTSi contained in 1 OTSiG. The list could also be of only 1 element"; leaf otsi-carrier-id { type uint16; description "OTSi carrier-id"; } leaf otsi-carrier-frequency { type union { type l0-types:frequency-thz; type empty; } description "OTSi carrier frequency, equivalent to the actual configured transmitter frequency"; } leaf-list nmc-path-id { type uint16; description "The list of the possible Network Media Channel (NMC) paths associated with the OTSi which have different optical impairments. This list is meaningful in case the OTSi can be associated with multiple NMC paths (e.g., when OPS protection is configured). The list can be empty when the OTSi has only one NMC path."; } } // OTSi list } // OTSiG grouping grouping media-channel-groups { description "media channel groups"; list media-channel-group { key "i"; description "list of media channel groups"; leaf i { type int16; description "index of media channel group member"; } list media-channels { key "flexi-n"; description "list of media channels represented as (n,m)"; // this grouping add both n.m values uses l0-types:flexi-grid-frequency-slot; leaf otsi-group-ref { type leafref { path "/nw:networks/nw:network/otsi-group/otsi-group-id"; } description "Reference to the otsi-group list to get otsi-group identifier of the OTSiG carried by this media channel that reports the transient stat"; } list otsi-ref { description "The list of references to the OTSis and their NMC paths within the OTSiG carried by this media channel."; leaf otsi-carrier-ref { type leafref { path "/nw:networks/nw:network/" + "otsi-group[otsi-group-id=current()" + "/../../otsi-group-ref]/" + "otsi/otsi-carrier-id" ; } description "Reference to the OTSi within the OTSiG carried by this media channel."; } leaf-list nmc-path-ref { type leafref { path "/nw:networks/nw:network/" + "otsi-group[otsi-group-id=current()" + "/../../otsi-group-ref]/" + "otsi[otsi-carrier-id=current()" + "/../otsi-carrier-ref]/nmc-path-id" ; } description "References to the NMC paths of this OTSi which are routed through this media channel."; } } leaf delta-power { type l0-types:power-in-dbm-or-null; 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 "OMS description"; list OMS-elements { key "elt-index"; description "defines the spans and the amplifier blocks of the amplified lines"; leaf elt-index { type uint16; description "ordered list of Index of OMS element (whether it's a Fiber, an EDFA or a Concentratedloss)"; } leaf oms-element-uid { type union { type string; type empty; } description "unique id of the element if it exists"; } 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/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 concentratedloss { uses concentratedloss-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 "../../../../../otsi-group/otsi-group-id"; } description "The OTSi generated by the transceiver's transmitter."; } leaf otsi-ref { type leafref { path "../../../../../otsi-group[otsi-group-id=" + "current()/../otsi-group-ref]/otsi/otsi-carrier-id"; } description "The OTSi generated by the transceiver's transmitter."; } } /* 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"; } } augment "/nw:networks/nw:network" { when "nw:network-types/tet:te-topology" + "/optical-imp-topo:optical-impairment-topology" { description "This augment is only valid for Optical Impairment."; } description "Network augmentation for optical impairments data."; list otsi-group { key "otsi-group-id"; config false; 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 an URI or as an UUID."; } uses otsi-group; } // list of OTSiG } augment "/nw:networks/nw:network/nw:node" { when "../nw:network-types/tet:te-topology" + "/optical-imp-topo:optical-impairment-topology" { description "This augment is only valid for Optical Impairment."; } description "Node augmentation for optical impairments data."; list transponder { key "transponder-id"; config false; description "list of transponder"; 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 configure to 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"; config false; description "list of transceiver related to a transponder"; leaf transceiver-id { type uint32; description "transceiver identifier"; } uses l0-types:transceiver-capabilities; leaf configured-mode { type leafref { path "../supported-modes/supported-mode/mode-id"; } description "Reference to the configured mode for transceiver compatibility approach."; } uses l0-types:common-transceiver-configured-param; container outgoing-otsi { description "The OTSi generated by the transceiver's transmitter."; uses otsi-ref; } container incoming-otsi { description "The OTSi received by the transceiver's received."; uses otsi-ref; } leaf configured-termination-type { type enumeration { 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 transcevier is not used."; } } // end of list of transceiver } // end list of transponder list regen-group { key "group-id"; config false; description "List of 3R groups. Any 3R group represent a group of transponder in which an a 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 group of transponders during path computation"; } leaf-list transponder-ref { type leafref { path "../../transponder/transponder-id"; } description "The list of transponder belonging to this 3R group."; } } // end 3R-group } augment "/nw:networks/nw:network/nt:link/tet:te" + "/tet:te-link-attributes" { when "/nw:networks/nw:network/nw:network-types" + "/tet:te-topology/" + "optical-imp-topo:optical-impairment-topology" { description "This augment is only valid for Optical Impairment."; } 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:networks/nw:network/nw:network-types" + "/tet:te-topology/" + "optical-imp-topo:optical-impairment-topology" { description "This augment is only valid for Impairment with non-sliceable transponder model"; } description "Tunnel termination point augmentation for non-sliceable transponder model."; list ttp-transceiver { key "transponder-ref transceiver-ref"; config false; description "The list of the transceivers used by the TTP."; leaf transponder-ref { type leafref { path "../../../../transponder/transponder-id"; } description "The reference to the transponder hosting the transceiver of the TTP."; } leaf transceiver-ref { type leafref { path "../../../../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/tet:te" + "/tet:tunnel-termination-point" { when "/nw:networks/nw:network/nw:network-types" +"/tet:te-topology/" + "optical-imp-topo:optical-impairment-topology" { description "This augment is only valid for optical impairment with sliceable transponder model"; } description "Tunnel termination point augmentation for sliceable transponder model."; uses sliceable-transponder-attributes; } augment "/nw:networks/nw:network/nw:node/tet:te" + "/tet:te-node-attributes" { when "/nw:networks/nw:network/nw:network-types" + "/tet:te-topology" + "/optical-imp-topo:optical-impairment-topology" { description "This augment is only valid for Optical Impairment topology"; } description "node attributes augmentantion for optical-impairment ROADM node"; list roadm-path-impairments { key "roadm-path-impairments-id"; config false; description "The set of optical impairments related to a ROADM path."; leaf roadm-path-impairments-id { type uint32; description "index of the ROADM path-impairment list"; } choice impairment-type { description "type path impairment"; case roadm-express-path { list roadm-express-path { 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."; container frequency-range { description "The frequency range for which these optical impairments apply."; uses l0-types:frequency-range; } uses roadm-express-path; } } case roadm-add-path { list roadm-add-path { 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."; container frequency-range { description "The frequency range for which these optical impairments apply."; uses l0-types:frequency-range; } uses roadm-add-path; } } case roadm-drop-path { list roadm-drop-path { 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."; container frequency-range { description "The frequency range for which these optical impairments apply."; uses l0-types:frequency-range; } uses roadm-drop-path; } } } } // list path impairments } // augmentation for optical-impairment ROADM augment "/nw:networks/nw:network/nw:node/tet:te/" + "tet:information-source-entry/tet:connectivity-matrices"{ when "/nw:networks/nw:network/nw:network-types" + "/tet:te-topology/" + "optical-imp-topo:optical-impairment-topology" { description "This augment is only valid for Optical Impairment topology "; } description "Augment default TE node connectivity matrix information source."; leaf roadm-path-impairments { type leafref { path "../../../tet:te-node-attributes/" + "roadm-path-impairments/roadm-path-impairments-id"; } description "pointer to the list set of ROADM optical impairments"; } } // augmentation connectivity-matrices information-source augment "/nw:networks/nw:network/nw:node/tet:te/" + "tet:information-source-entry/tet:connectivity-matrices/" + "tet:connectivity-matrix" { when "/nw:networks/nw:network/nw:network-types" + "/tet:te-topology/" + "optical-imp-topo:optical-impairment-topology" { description "This augment is only valid for Optical Impairment topology "; } description "Augment TE node connectivity matrix entry information source."; leaf roadm-path-impairments { type leafref { path "../../../../tet:te-node-attributes/" + "roadm-path-impairments/roadm-path-impairments-id"; } description "pointer to the list set of ROADM optical impairments"; } } // augmentation connectivity-matrix information-source augment "/nw:networks/nw:network/nw:node/tet:te/" + "tet:te-node-attributes/tet:connectivity-matrices" { when "/nw:networks/nw:network/nw:network-types" + "/tet:te-topology/" + "optical-imp-topo:optical-impairment-topology" { description "This augment is only valid for Optical Impairment topology "; } description "Augment default TE node connectivity matrix."; leaf roadm-path-impairments { type leafref { path "../../roadm-path-impairments/" + "roadm-path-impairments-id"; } config false; /*the identifier in the list */ /*"roadm-path-impairments" of ROADM optical impairment*/ /*is read-only as the rest of attributes*/ description "pointer to the list set of ROADM optical impairments"; } } // augmentation connectivity-matrices augment "/nw:networks/nw:network/nw:node/tet:te/" + "tet:te-node-attributes/" + "tet:connectivity-matrices/tet:connectivity-matrix" { when "/nw:networks/nw:network/nw:network-types" + "/tet:te-topology/" + "optical-imp-topo:optical-impairment-topology" { description "This augment is only valid for Optical Impairment topology "; } description "Augment TE node connectivity matrix entry."; leaf roadm-path-impairments { type leafref { path "../../../roadm-path-impairments/" + "roadm-path-impairments-id"; } config false; description "pointer to the list set of ROADM optical impairments"; } } // augmentation connectivity-matrix augment "/nw:networks/nw:network/nw:node/tet:te/" + "tet:tunnel-termination-point/" + "tet:local-link-connectivities" { when "/nw:networks/nw:network/nw:network-types" + "/tet:te-topology/" + "optical-imp-topo:optical-impairment-topology" { description "This augment is only valid for Optical Impairment topology "; } description "Augment default TTP LLC."; leaf add-path-impairments { type leafref { path "../../../tet:te-node-attributes/" + "roadm-path-impairments/roadm-path-impairments-id" ; } config false; description "pointer to the list set of ROADM optical impairments"; } leaf drop-path-impairments { type leafref { path "../../../tet:te-node-attributes/" + "roadm-path-impairments/roadm-path-impairments-id" ; } config false; description "pointer to the list set of ROADM optical impairments"; } } // augmentation local-link-connectivities augment "/nw:networks/nw:network/nw:node/tet:te/" + "tet:tunnel-termination-point/" + "tet:local-link-connectivities/" + "tet:local-link-connectivity" { when "/nw:networks/nw:network/nw:network-types" + "/tet:te-topology/" + "optical-imp-topo:optical-impairment-topology" { description "This augment is only valid for Optical Impairment topology "; } description "Augment TTP LLC entry."; leaf add-path-impairments { type leafref { path "../../../../tet:te-node-attributes/" + "roadm-path-impairments/roadm-path-impairments-id" ; } config false; description "pointer to the list set of ROADM optical impairments"; } leaf drop-path-impairments { type leafref { path "../../../../tet:te-node-attributes/" + "roadm-path-impairments/roadm-path-impairments-id" ; } config false; description "pointer to the list set of ROADM optical impairments"; } list llc-transceiver { key "ttp-transponder-ref ttp-transceiver-ref"; config false; description "The list of transceivers having a 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 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 { type leafref { path "../../../../../tet:te-node-attributes/" + "roadm-path-impairments/roadm-path-impairments-id" ; } config false; description "pointer to the list set of ROADM optical impairments"; } leaf drop-path-impairments { type leafref { path "../../../../../tet:te-node-attributes/" + "roadm-path-impairments/roadm-path-impairments-id" ; } config false; description "pointer to the list set of ROADM optical impairments"; } } } // augmentation local-link-connectivity }

]]>



  
  
   The configuration, state, and action data defined in this document
   are designed to be accessed via a management protocol with a secure
   transport layer, such as NETCONF .  The
   NETCONF access control model  provides the
   means to restrict access for particular NETCONF users to a
   preconfigured subset of all available NETCONF protocol operations
   and content.
  

  
   A number of configuration data nodes defined in this document are
   read-only; however, these data nodes may be considered sensitive or
   vulnerable in some network environments (TBD).
  

  

  
  
   This document registers the following namespace URIs in the IETF XML
   registry [RFC3688]:
  

  
  
  
   This document registers the following YANG modules in the YANG
   Module Names registry :

  
  
  

  
  
   We thank Daniele Ceccarelli and Oscar G. De Dios for useful
   discussions and motivation for this work.



  
  
  
  
  &RFC2119;
  &RFC7950;
  &RFC8040;
  &RFC8341;
  &RFC8795;
  
  
  
  
  &RFC6241;
  &RFC6566;
  &RFC7446;
  &RFC7579;
  &RFC7581;
  &RFC7698;
  &RFC8340;
  &RFC8342;
  &RFC8345;
  &RFC8453;
  &RFC9093;
  &RFC9094;
  &I-D.ietf-ccamp-layer0-types-ext;
  &I-D.ietf-ccamp-dwdm-if-param-yang;
  &I-D.ietf-teas-te-topo-and-tunnel-modeling;
  
  
   
   Characteristics of multi-degree reconfigurable optical add/drop multiplexers
   
   
   
   
   
  

  
   
   Generic functional architecture of the optical media network
   
   
   
   
   
  
  
  
   
   Interfaces for the Optical Transport Network (OTN)
   
   
   
   
   
  
  
  
   
   Spectral grids for WDM applications: DWDM frequency grid
   
   
   
   
   
  
  
  
   
   Optical transport network physical layer interfaces
   
   
   
   
   
  

  
   
   Architecture of optical transport networks
   
   
   
   
   
  

  
   
   Amplified multichannel dense wavelength division multiplexing
          applications with single channel optical interfaces
   
   
   
   
   
   
  

  
   
   Types and characteristics of optical transport network equipment
   
   
   
   
   
  
  
  
   
   Optical transport network: Linear protection
   
   
   
   
   
  
  
  
    
  
  
  
  Aihua GuoHuawei Technologies
  Email: aguo@futurewei.com

  
  Jonas MartenssonRISE
  Email: jonas.martensson@ri.se
  
  

  
  
  
  Young LeeSamsung Electronics
  Email: younglee.tx@gmail.com
  
  
  Haomian ZhengHuawei Technologies
  Email: zhenghaomian@huawei.com
  
  
  Nicola SamboScuola Superiore Sant'Anna
  Email: nicosambo@gmail.com
  
  
  Giovanni MartinelliCisco
  Email: giomarti@cisco.com
  
  
  Jean-Luc AugeOrange
  Email: jeanluc.auge@orange.com
  
  
  Julien MeuricOrange
  Email: julien.meuric@orange.com
  
  
  Victor LopezNokia
  Email: Victor.Lopez@nokia.com
  
  
  Griseri EnricoNokia
  Email: Enrico.Griseri@nokia.com
  
  
  Gert GrammelJuniper
  Email: ggrammel@juniper.net