CCAMP Working Group Y. Lee Internet DraftH. ZhengFuturewei Intended Status: Standard TrackI. Busi HuaweiExpires:October 9,November 27, 2019N. Sambo Scuola Superiore Sant'AnnaV. Lopez Telefonica G. GalimbertiG. MartinelliCisco Jean Luc AugeEster LE Rouzic Julien MeuricOrange D. BellerS. Belotti E. GriseriNokiaGert Grammel Juniper April 9,May 27, 2019 A Yang Data Model for Optical Impairment-aware Topologydraft-ietf-ccamp-optical-impairment-topology-yang-00draft-ietf-ccamp-optical-impairment-topology-yang-01 Abstract 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. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire onOctober 9,November 27, 2019. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction...................................................3 1.1. Terminology...............................................4 1.2. Tree diagram..............................................4 1.3. Prefixes in Data NodeNames...............................5Names...............................4 2. ReferenceArchitecture.........................................6Architecture.........................................5 2.1. Control PlaneArchitecture................................6Architecture................................5 2.2. Transport DataPlane......................................7Plane......................................6 2.3. OMS Media Links...........................................7 2.3.1. Optical Tributary Signal (OTSi)......................7 2.3.2. Optical Tributary Signal Group(OTSiG)...............8(OTSiG)...............7 2.3.3. Media Channel Group (MCG)............................9 2.4.Amplifiers................................................9 2.4.1. In-Line Amplifier...................................10Amplifiers...............................................11 2.5.Transponders.............................................10Transponders.............................................11 2.6.WSS/Filter...............................................10WSS/Filter...............................................12 2.7. OpticalFiber............................................10Fiber............................................12 3. YANG Model (TreeStructure)...................................11Structure)...................................12 4. Optical Impairment Topology YANGModel........................12Model........................14 5. SecurityConsiderations.......................................31Considerations.......................................34 6. IANAConsiderations...........................................31Considerations...........................................34 7.Acknowledgments...............................................32Acknowledgments...............................................35 8.References....................................................33References....................................................36 8.1. NormativeReferences.....................................33References.....................................36 8.2. InformativeReferences...................................33References...................................36 9.Contributors..................................................34Contributors..................................................38 Authors'Addresses...............................................34Addresses...............................................38 1. Introduction 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) [RFC6566] 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 [RFC7446] and the two encoding documents [RFC7581] and [RFC7579] that developed protocol independent encodings based on [RFC7446]. 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 [RFC8453]. The communication between controllers is done via a NETCONF[RFC8341].[RFC8341] or a RESTCONF [RFC8040]. 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. This document augments the generic TE topology draft [TE-TOPO] where possible. This document defines one YANG module: ietf-optical-impairment- topology (Section 3) according to the new Network Management Datastore Architecture [RFC8342]. 1.1. Terminology Refer to[RFC4847][RFC6566], [RFC7698], and[RFC5253][G.807] for the key terms used in this document. The following terms are defined in [RFC7950] and are not redefined here: o client o server o augment o data model o data node The following terms are defined in [RFC6241] and are not redefined here: o configuration data o state data The terminology for describing YANG data models is found in [RFC7950]. 1.2. Tree diagram 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 [RFC8340]. 1.3. Prefixes in Data Node Names 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 Table 1. +------------------+----------------------------------+------------+ | Prefix | YANG module | Reference | +------------------+----------------------------------+------------+ | optical-imp-topo | ietf-optical-impairment-topology |[RFC XXXX][RFCXXXX] | | layer0-types | ietf-layer0-types |[WSON-topo]|[L0-Types] | | nw | ietf-network | [RFC8345] | | nt | ietf-network-topology | [RFC8345] | | tet | ietf-te-topology | [TE-TOPO] | +------------------+----------------------------------+------------+ Table 1: Prefixes and corresponding YANG modules Note: The RFC Editor will replace XXXX with the number assigned to the RFC once this draft becomes an RFC. 2. Reference Architecture 2.1. Control Plane Architecture Figure 1 shows the control plane architecture. +--------+ | MDSC | +--------+ Scope of this ID -------> || | || | +------------------------+ | | 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 draft-ietf-ccamp-dwdm-if-param-yang Figure 1. Control Plane Architecture The models developed in this document is an abstracted Yang model that may be used in the interfacescolored in yellowbetween the MDSC and the Optical Domain Controller (aka MPI) and between the Optical Domain Controller and the Optical Device (aka SBI) in Figure 1. It is not intended to support detaileddevice congiurationlow-level DWDM interface model.Device configurationDWDM interface model is supported by the models presented in[draft-ietf-ccamp-dwdm-if-parameter-yang].[draft-ietf- ccamp-dwdm-if-parameter-yang]. 2.2. Transport Data Plane This section provides the description of the reference optical network architecture and its relevant components to support optical impairment-aware path computation. Figure 2 shows the reference architecture. +-------------------+ +-------------------+ | ROADM Node | | ROADM Node | | | | | | PA +-------+ BA | ILAILA| PA +-------+ BA | | +-+ | WSS/ | +-+ | _____ +--+____ +--+_____ | +-+ | WSS/ | +-+ |---|-|--|-| |-|Filter |-| |-|-()____)--||-()___)-| |-()____)--|-||-()____)-|-| |-|Filter |-||-|---|-|-- | +-+ | | +-+ | +--++--+| +-+ | | +-+ | | +-------+ | optical | +-------+ | | | | | | fiber | | | | | | | | | | | | | | | | o-o-o | | o-o-o | | transponders | | transponders | +-------------------+ +-------------------+ OTS Link OTS LinkOTS Link -----------> -------->-----------> ----------> OMS Link---------------------------------------------->---------------------------------> PA: Pre-Amplifier BA: Booster Amplifier ILA: In-Line Amplifier Figure 2. Reference Architecture for Optical Transport Network BA (on the left side ROADM) is the ingress Amplifier and PA (on the right side ROADM is the egress amplifier for the OMS link shown in the Figure. 2.3. OMS Media Links According to [G.872], OMS Media Link represents a media link between two ROADM. Specifically, it originates at the ROADM's Filter in the source ROADM and terminates at the ROADM's Filter in the destination ROADM. OTS Media Link represents a media link: (i) between ROADM's BA and ILA; (ii) between a pair of ILAs; (iii) between ILA and ROADM's PA. OMS Media link can be decomposedofin anumbersequence ofelements, which are basicallyOTS links type (i), (ii), and (iii) as discussed above. OMS Media link would give an abstracted view of impairment data (e.g., power, OSNR, etc.) to the network controller. For the sake of optical impairment evaluation OMS Media link can be also decomposed in a sequence of elements such as BA, fiber section, ILA, concentrated loss and PA. 2.3.1. Optical Tributary SignalGroup (OTSiG)(OTSi) TheMedia Channel and Network Media Channel are well modelled by the RFC7698, RFC7699 and RFC7792 reflecting the ITU-T Recommendations G.694.1 and G.698.2. Some workOTSi isin progressdefined in ITU-TSG15/Q12 to define Network Media Channel (group)Recommendation G.959.1, section 3.2.4 [G.959.1]. The YANG model defined below assumes thatis capablea single OTSi consists ofaccommodating thea single modulated opticaltributary signals (OTSi) belonging tocarrier. This single modulated opticaltributary signal group (OTSiG). ( see new ITU-T Draft Recommendation G.807)). Currently, no models exist (in the IETF nor ITU-T SG15) that define howcarrier conveys digital information. Characteristics of theoptical tributary signalsOTSi signal aredescribed insidemodulation scheme (e.g. QPSK, 8-QAM, 16-QAM, etc.), baud rate (measure of theNetwork Media Channelsymbol rate), pulse shaping (e.g. raised cosine - complying with the Nyquist inter symbol interference criterion), etc. 2.3.2. Optical Tributary Signal Groupin terms(OTSiG) The definition ofOTSi identifier, OTSi carrier frequency and OTSi signal width. There are several options howthementioned parameters can be described. One optionOTSiG is currently being moved from ITU-T Recommendation G.709 [G.709] tousethedescription defined in draft- ggalimbe-ccamp-flexigrid-carrier-label. A second optionnew draft Recommendation G.807 (still work in progress) [G.807]. The OTSiG isto describean electrical signal that is carried by one or more OTSi's. The relationship between theOTsi carrier frequency relative toOTSiG and theanchor frequency 193.1THz based onthe OTSi's is described in ITU-T draft Recommendation G.807, section 10.2 [G.807]. The YANG model below supports both cases: the single OTSi case where the OTSiG contains awell-defined granularity (e.g.single OTSicarrier frequency = 193100 (GHz) + K * granularity (GHz)(see ITU-T draft Recommendation G.807, Figure 10-2) and the multiple OTSi case whereK isthe OTSiG consists of more than one OTSi (see ITU-T draft Recommendation G.807, Figure 10-3). From asigned integer value). A third optionlayer 0 topology YANG model perspective, the OTSiG is a logical construct that associates the OTSi's, which belong toexplicitly describethe same OTSiG. The typical application of an OTSiG consisting of more than one OTSicarrier frequencyis 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) theOTSidifferential delay between the different OTSi's may not exceed a certain limit. Example: a 400Gbps client signalwidthmay be carried by 4 OTSi's where each OTSi carries 100Gbps of client traffic. OTSiG __________________________/\__________________________ / \ m=7 - - - +---------------------------X---------------------------+ - - / / / | | / / / / /| OTSi OTSi OTSi OTSi |/ / / / / / | ^ ^ ^ ^ | / / / / /| | | | | |/ / / / / / | | | | | | / / / / /| | | | | |/ / / -4 -3 -2 -1 0 1 2 3 4 5 6 7 8 9 10 11 12 --+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+--- n = ? K1 K2 K3 K4 2.3.3 Media Channel (MC) The definition of the MC is currently being moved from ITU-T Recommendation G.872 [G.872] to the new draft Recommendation G.807 (still work inGHzprogress) [G.807]. Section 3.2.2 defines the term MC and section 7.1.2 provides a more detailed description with some examples. The definition of the MC is very generic (see ITU-T draft Recommendation G.807, Figure 7-1). In the YANG model below, the MC is used with the following semantics: The MC is an end-to-end topological network construct and can be considered as an "optical pipe" with acertain accuracy. Itwell-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 isproposedassumed that these OTSi's belong tousethethird option whichsame OTSiG. m=8 +-------------------------------X------------------------------+ | | | | +----------X----------+ | +----------X----------+ | | | OTSi | | OTSi | | | | o | | | o | | | | | | | | | | -4 -3 -2 -1 0 1 2 3 4 5 6 7 8 9 10 11 12 --+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+-- | n=4 | K1 K2 <------------------------ Media Channel -----------------------> The frequency slot of the MC isindependentdefined by the n value defining the central frequency of then,MC and the mvalues alredy definevalue that defines the width of the MC following the flexible grid definition in ITU-T RecommendationG.694.1. The OTSi carrierG.694.1 [G.694.1]. In this model, the effective frequencyis describedslot as defined inGHz with 3 fractional digits (decimal 64 fraction digits 3).ITU-T draft Recommendation G.807 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. 2.3.3. Media Channel Group (MCG) TheOTSi signal widthdefinition of the MCG isdescribedcurrently work inGHz with 3 fractional digits (decimal 64 fraction digits 3)progress in ITU-T andincludesis defined in section 7.1.3 of thesignal roll off as well as some guard band.new ITU-T draft Recommendation G.807 (still work in progress) [G.807]. Theaccuracy of 0.001 GHz does not imposeYANG model below assumes that the MCG is arequirement onlogical grouping of one or more MCs that are used to to carry all OTSi's belonging to theoptical transceiver components (optical transmitter) in termssame OTSiG. The MCG can be considered as an association ofcarrier frequency tuneability precision. Today's components typically provideMCs without defining atunability precision inhierarchy 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 therangesame OTSiG. In such a case the set of1..1.5GHz (carrier frequency offset comparedOTSi's belonging to a single OTSiG have to be split across 2 or more MCs. MCG1 = {M1.1, M1.2} _______________________/\_____________________________ / \ M1.1 M2 M1.2 ________/\____________ _____/\______ ____/\_____ / \ / \/ \ - - +-------------------------------------------------------+ - - / / | | / / / / / / /| | / / / /| OTSi OTSi OTSi |/ / / / / / / | OTSi |/ / / / | ^ ^ ^ | / / / / / / /| ^ | / / / /| | | | |/ / / / / / / | | |/ / / / | | | | | / / / / / / /| | | / / / /| | | | |/ / / / / / / | | |/ / -7 -1 0 1 2 3 4 5 6 7 8 9 10 . . . . . 17 . . 21 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ n=0 n=11 n=17 K1 K2 K3 K4 The MCG is relevant for path computation because all end-to-end MCs belonging to theconfigured nominal carrier frequency). Future components may provide a better precision as technology evolves. If needed, a controller may retrieve the transceiver properties in terms of carrier frequency tuneability precision in ordersame MCG have to becapableco-routed, i.e., have to follow the same path. Additional constraints may exist (e.g. differential delay). 2.4. Amplifiers Optical amplifiers are in charge ofproperly configuring the underlying transceiver. [Note fromamplifying theEditor]: As this description is arbitrarily proposed byoptical signal in theauthorsoptical itself without any electrical conversion. There are three main technologies tocover a lackbuild amplifiers: Erbium Doped Fiber Amplifier (EDFA), Raman Fiber Amplifier (RFA), and Semiconductor Optical Amplifier (SOA). Nowadays, most ofinformationoptical networks uses EDFAs. However, RFA has an attractive feature that it works inIETF and ITU-T,any wavelength band with aliaison request to ITU-T is needed. The authors are willing to contribute to Liaison editing andsimilar or lower noise figures compared toconsider any feedbackEDFA. On the other hand, RFAs consumes more power andproposal from ITU-T. 2.4.are more expensive than EDFAs. Amplifiers can be classified according to their location in the communication link. There are three basic types ofamplifiers.amplifiers: ILA, Pre-Amplifier and Booster. ILA is In-Line Amplifier which is a separate node type while Pre-Amplifier and Booster Amplifier are integral elements of ROADM node. From a data modeling perspective, Pre-Amplifier and Booster Amplifier are internal functions of a ROADM node and as such these elements are hidden within ROADM node. In this document, we would avoid internal node details, but attempt to abstract as much as possible. 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).2.4.1. In-Line Amplifier (Need to explain details including VOA)2.5. Transponders A Transponder is the element that sends and receives the optical signal from a fiber. A transponder is typically characterized by its data rate and the maximum distance the signal can travel. Channel frequency, per channel input power, FEC and Modulation are also associated with a transponder. From a path computation point of view, the selection of the compatible source and destination transponders is an important factor for optical signal to traverse through the fiber. There are three main approaches to determine optical signal compatibility. Application Code based onG.682.2G.698.2 is one approach that only checks the code at both ends of theinterface.link. Another approach is organization codes that are specific to an organization or a vendor. The third approach is specify all the relevant parameters explicitly, e.g., FEC type, Modulation type, etc. [Editor's Note: The current YANG model described in Section 3 with respect to the relationship between the transponder attributes and the OTSi will need to be investigated in the future revision] 2.6. WSS/Filter 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. 2.7. Optical Fiber 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. 3. YANG Model (Tree Structure) module: ietf-optical-impairment-topology augment /nw:networks/nw:network/nw:network-types/tet:te-topology: +--rw optical-impairment-topology! augment /nw:networks/nw:network/nt:link/tet:te/tet:te-link-attributes: +--ro OMS-attributes +--ro generalized-snr? decimal64 +--ro equalization-mode identityref +--ro (power-param)? | +--:(channel-power) | | +--ro nominal-channel-power? decimal64 | +--:(power-spectral-density) | +--ro nominal-power-spectral-density? decimal64 +--ronetwork-media-channel-group*media-channel-group* [i] | +--ro i int16 | +--rocurrent-channels* [flex-n] |media-channels* [flexi-n] | +--roflex-nflexi-n uint16 ||+--roflex-m?flexi-m? uint16 | +--roOTSiG-container* [carrier-id] | +--ro carrier-id int16 | +--ro OTSi-carrier-frequency? decimal64 | +--ro OTSi-signal-width? decimal64OTSiG-ref? leafref | +--rochannel-delta-power? decimal64OTSi-ref? leafref +--ro OMS-elements* [elt-index] +--ro elt-index uint16 +--ro uid? string +--ro type identityref +--ro element +--ro (element)? +--:(amplifier) | +--ro amplifier | +--ro type_variety string | +--ro operational | +--ro actual-gain | | decimal64 | +--ro tilt-target | | decimal64 | +--ro out-voa | | decimal64 | +--ro in-voa | | decimal64 | +--ro (power-param)? | +--:(channel-power) | | +--ro nominal-channel-power? | | decimal64 | +--:(power-spectral-density) | +--ro nominal-power-spectral-density? | decimal64 +--:(fiber) | +--ro fiber | +--ro type_variety string | +--ro length decimal64 | +--ro loss_coef decimal64 | +--ro total_loss decimal64 | +--ro pmd? decimal64 | +--ro conn_in? decimal64 | +--ro conn_out? decimal64 +--:(concentratedloss) +--ro concentratedloss +--ro loss? decimal64 augment/nw:networks/nw:network/nw:node/tet:te/tet:tunnel-termination-point:/nw:networks/nw:network/nw:node/tet:te /tet:tunnel-termination-point: +--ro OTSiG-element* [OTSiG-identifier] | +--ro OTSiG-identifier int16 | +--ro OTSiG-container | +--ro OTSi* [OTSi-carrier-id] | +--ro OTSi-carrier-id int16 | +--ro OTSi-carrier-frequency? decimal64 | +--ro OTSi-signal-width? decimal64 | +--ro channel-delta-power? decimal64 +--ro transponders-list* [transponder-id] +--ro transponder-id uint32 +--ro (mode)? | +--:(G.692.2) | | +--roG.692.2?standard_mode? layer0-types:standard-mode | +--:(organizational_mode) | | +--ro operational-mode? | | | layer0-types:operational-mode | | +--ro organization-identifier? | | layer0-types:vendor-identifier | +--:(explicit_mode) | +--ro available-modulation* identityref | +--ro modulation-type? identityref | +--ro available-baud-rates* uint32 | +--ro configured-baud-rate? uint32 | +--ro available-FEC* identityref | +--ro FEC-type? identityref | +--ro FEC-code-rate? decimal64 | +--ro FEC-threshold? decimal64 +--ro power? int32 +--ro power-min? int32 +--ro power-max? int32 augment/nw:networks/nw:network/nw:node/tet:te/tet:tunnel-termination-point:/nw:networks/nw:network/nw:node/tet:te /tet:tunnel-termination-point: +--ro transponder-list* [carrier-id] +--ro carrier-id uint32 4. Optical Impairment Topology YANG Model <CODE BEGINS> fileietf-optical-impairment-topology@2018-02-27.yangietf-optical-impairment-topology@2018-05-22.yang 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 "layer0-types"; } organization "IETF CCAMP Working Group"; contact "Editor: Young Lee<leeyoung@huawei.com><younglee.tx@gmail.com> Editor: Haomian Zheng <zhenghaomian@huawei.com> Editor: Nicola Sambo <nicosambo@gmail.com> Editor: Victor Lopez <victor.lopezalvarez@telefonica.com> Editor: Gabriele Galimberti <ggalimbe@cisco.com> Editor: Giovanni Martinelli <giomarti@cisco.com> Editor: Auge Jean-Luc <jeanluc.auge@orange.com> Editor: Le Rouzic Esther <esther.lerouzic@orange.com> Editor: Julien Meuric <julien.meuric@orange.com> Editor: Italo Busi<Italo.Busi@huawei.com>";<Italo.Busi@huawei.com> Editor: Dieter Beller <dieter.beller@nokia.com> Editor: Sergio Belotti <Sergio.belotti@nokia.com> Editor: Griseri Enrico <enrico.griseri@nokia.com> Editor: Gert Grammel <ggrammel@juniper.net>"; description "This module contains a collection of YANG definitions for impairment-aware optical networks. Copyright (c) 2019 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 Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info)."; revision2019-02-272019-05-22 { description "Initial Version"; reference "RFC XXXX: A Yang Data Model for Impairment-aware Optical Networks"; } identity modulation { description "base identity for modulation type"; } identity QPSK { base modulation; description "QPSK (Quadrature Phase Shift Keying) modulation"; } identity DP_QPSK { base modulation; description "DP-QPSK (Dual Polarization Quadrature Phase Shift Keying) modulation"; } identity QAM8 { base modulation; description "8QAM (8-State Quadrature Amplitude Modulation) modulation"; } identity QAM16 { base modulation; description "QAM16 (Quadrature Amplitude Modulation)"; } identity DP_QAM8 { base modulation; description "DP-QAM8 (Dual Polarization Quadrature Amplitude Modulation)"; } identity DC_DP_QAM8 { base modulation; description "DC DP-QAM8 (Dual Polarization Quadrature Amplitude Modulation)"; } identity DP_QAM16 { base modulation; description "DP-QAM16 (Dual Polarization Quadrature Amplitude Modulation)"; } identity DC_DP_QAM16 { base modulation; description "DC DP-QAM16 (Dual Polarization Quadrature Amplitude Modulation)"; } identity FEC { description "Enumeration that defines the type of Forward Error Correction"; } identity reed-solomon { base FEC; description "Reed-Solomon error correction"; } identity hamming-code { base FEC; description "Hamming Code error correction"; } identity golay { base FEC; description "Golay error correction"; } typedef fiber-type { type enumeration { enum G.652 { description "G.652 Standard Singlemode Fiber"; } enum G.654 { description "G.654 Cutoff Shifted Fiber"; } enum G.653 { description "G.653 Dispersion Shifted Fiber"; } enum G.655 { description "G.655 Non-Zero Dispersion Shifted Fiber"; } enum G.656 { description "G.656 Non-Zero Dispersion for Wideband Optical Transport"; } enum G.657 { description "G.657 Bend-Insensitive Fiber"; } } description "ITU-T based fiber-types"; } grouping transponder-attributes { description "Configuration of an optical transponder"; leaf-list available-modulation { type identityref { base modulation; } config false; description "List determining all the available modulations"; } leaf modulation-type { type identityref { base modulation; } config false; description "Modulation configured for the transponder"; } leaf-list available-baud-rates { type uint32; units Bd; config false; description "list of available baud-rates. Baud-rate is the unit for symbol rate or modulation rate in symbols per second or pulses per second. It is the number of distinct symbol changes (signaling events) made to the transmission medium per second in a digitally modulated signal or a line code"; } leaf configured-baud-rate { type uint32; units Bd; config false; description "configured baud-rate"; } leaf-list available-FEC { type identityref { base FEC; } config false; description "List determining all the available FEC"; } leaf FEC-type { type identityref { base FEC; } config false; description "FEC type configured for the transponder"; } leaf FEC-code-rate { type decimal64 { fraction-digits 8; range "0..max"; } config false; description "FEC-code-rate"; } leaf FEC-threshold { type decimal64 { fraction-digits 8; range "0..max"; } config false; description "Threshold on the BER, for which FEC is able to correct errors"; } } grouping sliceable-transponder-attributes { description "Configuration of a sliceable transponder."; list transponder-list { key "carrier-id"; config false; description "List of carriers"; leaf carrier-id { type uint32; config false; description "Identifier of the carrier"; } } } grouping optical-fiber-data { description "optical link (fiber) attributes with impairment data"; leaf fiber-type { type fiber-type; config false; description "fiber-type"; } leaf span-length { type decimal64 { fraction-digits 2; } units "km"; config false; description "the lenght of the fiber span in km"; } leaf input-power { type decimal64 { fraction-digits 2; } units "dBm"; config false; description "Average input power level estimated at the receiver of the link"; } leaf output-power { type decimal64 { fraction-digits 2; } units "dBm"; description "Mean launched power at the transmitter of the link"; } leaf pmd { type decimal64 { fraction-digits 8; range "0..max"; } units "ps/(km)^0.5"; config false; description "Polarization Mode Dispersion"; } leaf cd { type decimal64 { fraction-digits 5; } units "ps/nm/km"; config false; description "Cromatic Dispersion"; } leaf osnr { type decimal64 { fraction-digits 5; } units "dB"; config false; description "Optical Signal-to-Noise Ratio (OSNR) estimated at the receiver"; } leaf sigma { type decimal64 { fraction-digits 5; } units "dB"; config false; description "sigma in the Gausian Noise Model"; } } grouping optical-channel-data { description "optical impairment data per channel/wavelength"; leaf bit-rate { type decimal64 { fraction-digits 8; range "0..max"; } units "Gbit/s"; config false; description "Gross bit rate"; } leaf BER { type decimal64 { fraction-digits 18; range "0..max"; } config false; description "BER (Bit Error Rate)"; } leaf ch-input-power { type decimal64 { fraction-digits 2; } units "dBm"; config false; description "Per channel average input power level estimated at the receiver of the link"; } leaf ch-pmd { type decimal64 { fraction-digits 8; range "0..max"; } units "ps/(km)^0.5"; config false; description "per channel Polarization Mode Dispersion"; } leaf ch-cd { type decimal64 { fraction-digits 5; } units "ps/nm/km"; config false; description "per channel Cromatic Dispersion"; } leaf ch-osnr { type decimal64 { fraction-digits 5; } units "dB"; config false; description "per channel Optical Signal-to-Noise Ratio (OSNR) estimated at the receiver"; } leaf q-factor { type decimal64 { fraction-digits 5; } units "dB"; config false; description "q-factor estimated at the receiver"; } } grouping standard_mode { description "ITU-T G.698.2 standard mode that guarantees interoperability. It must be an string with the following format: B-DScW-ytz(v) where all these attributes are conformant to the ITU-T recomendation"; leaf standard_mode { type layer0-types:standard-mode; config false; description "G.698.2 standard mode"; } } grouping organizational_mode { description "Transponder operational mode supported by organizations or vendor"; leaf operational-mode { type layer0-types:operational-mode; config false; description "configured organization- or vendor-specific application identifiers (AI) supported by the transponder"; } leaf organization-identifier { type layer0-types:vendor-identifier; config false; description "organization identifier that uses organizational mode"; } } /* * Identities */ identity type-element { description "Base identity for element type"; } identity Fiber { base type-element; description "Fiber element"; } identity Roadm { base type-element; description "Roadm element"; } identity Edfa { base type-element; description "Edfa element"; } identity Concentratedloss { base type-element; description "Concentratedloss element"; } identity type-power-mode { description "power equalization mode used within the OMS and its elements"; } identity power-spectral-density { base type-power-mode; description "all elements must use power spectral density (W/Hz)"; } identity channel-power { base type-power-mode; description "all elements must use power (dBm)"; } /* * Groupings */ grouping amplifier-params { description "describes parameters for an amplifier"; container amplifier{ description "amplifier type, operatonal parameters are described"; leaf type_variety { type string ; mandatory true ; description "String identifier of amplifier type referencing a specification in a separate equipment catalog"; } container operational { description "amplifier operationnal parameters"; leaf actual-gain { type decimal64 { fraction-digits 2; } units dB ; mandatory true ; description ".."; } leaf tilt-target { type decimal64 { fraction-digits 2; } mandatory true ; description ".."; } leaf out-voa { type decimal64 { fraction-digits 2; } units dB; mandatory true; description ".."; } leaf in-voa { type decimal64 { fraction-digits 2; } units dB; mandatory true; description ".."; } uses power-param; } } } grouping fiber-params { description "String identifier of fiber type referencing a specification in a separate equipment catalog"; container fiber { description "fiber characteristics"; leaf type_variety { type string ; mandatory true ; description "fiber type"; } leaf length { type decimal64 { fraction-digits 2; } units km; mandatory true ; description "length of fiber"; } leaf loss_coef { type decimal64 { fraction-digits 2; } units dB/km; mandatory true ; description "loss coefficient of the fiber"; } leaf total_loss { type decimal64 { fraction-digits 2; } units dB; mandatory true ; description "includes all losses: fiber loss and conn_in and conn_out losses"; } leaf pmd{ type decimal64 { fraction-digits 2; } units sqrt(ps); description "pmd of the fiber"; } leaf conn_in{ type decimal64 { fraction-digits 2; } units dB; description "connector-in"; } leaf conn_out{ type decimal64 { fraction-digits 2; } units dB; description "connector-out"; } } } grouping roadm-params{ description "roadm parameters description"; container roadm{ description "roadm parameters"; leaf type_variety { type string ; mandatory true ; description "String identifier of roadm type referencing a specification in a separate equipment catalog"; } leaf loss { type decimal64 { fraction-digits 2; } units dB ; description ".."; } } } grouping concentratedloss-params{ description "concentrated loss"; container concentratedloss{ description "concentrated loss"; leaf loss { type decimal64 { fraction-digits 2; } units dB ; description ".."; } } } grouping power-param{ description "optical power or PSD after the ROADM or after the out-voa"; choice power-param { description "select the mode: channel power or power spectral density"; case channel-power { /* when"../../equalization-mode='channel-power'";"equalization-mode='channel-power'"; */ leaf nominal-channel-power{ type decimal64 { fraction-digits 1; } units dBm ; description " Reference channel power after the ROADM or after the out-voa. "; } } case power-spectral-density{ /* when"../../equalization-mode='power-spectral-density'";"equalization-mode='power-spectral-density'"; */ leaf nominal-power-spectral-density{ type decimal64 { fraction-digits 16; } units W/Hz ; description " Reference power spectral density after the ROADM or after the out-voa. Typical value : 3.9 E-14, resolution 0.1nW/MHz"; } } } } grouping oms-general-optical-params { description "OMS link optical parameters"; leaf generalized-snr { type decimal64 { fraction-digits 5; } units "dB@0.1nm"; description "generalized snr"; } leaf equalization-mode{ type identityref { base type-power-mode; } mandatory true; description "equalization mode"; } uses power-param; } groupingnetwork-media-channel-groupOTSiG { description"network media channel group"; list network-media-channel-group { key "i"; description "list of network media channel group's member"; leaf i"OTSiG definition , representing client digital information stream supported by 1 or more OTSi"; container OTSiG-container {type int16;config false; description"index"the container contains the related list ofnetwork media channel group member"; }OTSi. The listcurrent-channels { key "flex-n"; description "listcould also be ofmedia channels in the OMS"; uses layer0-types:flex-grid-channel; }only 1 element"; listOTSiG-containerOTSi { key"carrier-id";"OTSi-carrier-id"; description "list ofOTSiOTSi's under OTSi-G"; leafcarrier-idOTSi-carrier-id { type int16; description"carrier-id under OTSi-G";"OTSi carrier-id"; } leaf OTSi-carrier-frequency { type decimal64 { fraction-digits 3; } units GHz; config false; description "OTSi carrier frequency"; } leaf OTSi-signal-width { type decimal64 { fraction-digits 3; } units GHz; config false; description "OTSi signal width"; } leaf channel-delta-power { type decimal64 { fraction-digits 2; } units dB; config false; description "optional ; delta power to ref channel input-power applied to this media channel"; } } } // OTSiG container } // OTSiG grouping 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)"; uses layer0-types:flexi-grid-channel; leaf OTSiG-ref { type leafref { path "/nw:networks/nw:network/nw:node/tet:te" + "/tet:tunnel-termination-point/OTSiG-element/OTSiG-identifier" ; } description "Reference to the OTSiG list to get OTSiG identifier of the OSiG carried by this media channel that reports the transient stat"; } leaf OTSi-ref { type leafref { path "/nw:networks/nw:network/nw:node/tet:te" + "/tet:tunnel-termination-point/OTSiG-element[OTSiG- identifier=current()/../OTSiG-ref]/"+ "OTSiG-container/OTSi/OTSi-carrier-id" ; } description "Reference to the OTSi list supporting the related OTSiG" ; } } // media channels list } // media-channel-groups list } // media media-channel-groups grouping grouping oms-element { description "OMS description"; list OMS-elements { key "elt-index"; description "defines the spans and the amplifier blocks of the amplified lines"; leaf elt-index { type uint16; description "ordered list of Index of OMS element (whether it's a Fiber, an EDFA or a Concentratedloss)"; } leaf uid { type string; description "unique id of the element if it exists"; } leaf type { type identityref { base type-element; } mandatory true; description "element type"; } container element { description "element of the list of elements of the OMS"; choice element { description "OMS element type"; case amplifier { /* when"../..type"type = 'Edfa'"; */ uses amplifier-params ; } case fiber { /* when"../../type"type = 'Fiber'"; */ uses fiber-params ; } case concentratedloss { /* when"../../type"type = 'Concentratedloss'"; */ uses concentratedloss-params ; } } } } } /* Data nodes */ augment "/nw:networks/nw:network/nw:network-types" + "/tet:te-topology" { description "optical-impairment topology augmented"; container optical-impairment-topology { presence "indicates an impairment-aware topology of optical networks"; description "Container to identify impairment-aware topology type"; } } 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; usesnetwork-media-channel-group;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 OTSiG-element { key "OTSiG-identifier"; config false; description "the list of possible OTSiG representing client digital stream"; leaf OTSiG-identifier { type int16; description "index of OTSiG element"; } uses OTSiG; } list transponders-list { key "transponder-id"; config false; description "list of transponders"; leaf transponder-id { type uint32; description "transponder identifier"; } choice mode { description "standard mode, organizational mode or explicit mode"; case G.692.2 { uses standard_mode; } case organizational_mode { uses organizational_mode; } case explicit_mode { uses transponder-attributes; } } leaf power { type int32; units "dBm"; config false; description "per channel power"; } leaf power-min { type int32; units "dBm"; config false; description "minimum power of the transponder"; } leaf power-max { type int32; units "dBm"; config false; description "maximum power of the transponder"; } } } augment "/nw:networks/nw:network/nw:node/tet:te" + "/tet:tunnel-termination-point" { when "/nw:networks/nw:network/nw:network-types" +"/tet:te-topology/optical-imp-topo:optical-impairment-topology" { description "This augment is only valid for optical impairment with sliceable transponder model"; } description "Tunnel termination point augmentation for sliceable transponder model."; uses sliceable-transponder-attributes; } } <CODE ENDS> 5. Security Considerations 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 [RFC6241]. The NETCONF access control model [RFC6536] 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). 6. IANA Considerations This document registers the following namespace URIs in the IETF XML registry [RFC3688]: -------------------------------------------------------------------- URI: urn:ietf:params:xml:ns:yang:ietf-optical-impairment-topology Registrant Contact: The IESG. XML: N/A, the requested URI is an XML namespace. -------------------------------------------------------------------- This document registers the following YANG modules in the YANG Module Names registry [RFC7950]: -------------------------------------------------------------------- name: ietf-optical-impairment-topology namespace: urn:ietf:params:xml:ns:yang:ietf-optical-impairment- topology prefix: optical-imp-topo reference: RFC XXXX (TDB) -------------------------------------------------------------------- 7. Acknowledgments We thankDieter BellaDaniele Ceccarelli andSergio BelottiOscar G. De Dios for useful discussions and motivation for this work. 8. References 8.1. Normative References [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, August 2016. [RFC8040] A. Bierman, M. Bjorklund, K. Watsen, "RESTCONF Protocol", RFC 8040, January 2017. [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration Access Control Model", RFC 8341, March 2018. 8.2. Informative References [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, June 2011. [RFC6566] Y. Lee, G. Bernstein, D. Li, G. Martinelli, "A Framework for the Control of Wavelength Switched Optical Networks (WSONs) with Impairments", RFC 6566, March 2012. [RFC7446] Y. Lee, G. Bernstein, D. Li, W. Imajuku, "Routing and Wavelength Assignment Information Model for Wavelength Switched Optical Networks", RFC 7446, Feburary 2015. [RFC7579] G. Bernstein, Y. Lee, D. Li, W. Imajuku, "General Network Element Constraint Encoding for GMPLS Controlled Networks", RFC 7579, June 2015. [RFC7581] G. Bernstein, Y. Lee, D. Li, W. Imajuku, "Routing and Wavelength Assignment Information Encoding for Wavelength Switched Optical Networks", RFC 7581, June 2015.[RFC7950] Bjorklund, M.,[RFC7698] O. Gonzalez de Dios, Ed. and R. Casellas, Ed.,"The YANG 1.1 Data Modeling Language", RFC 7950, August 2016. [RFC8341] Bierman, A."Framework and Requirements for GMPLS-Based Control of Flexi-Grid Dense Wavelength Division Multiplexing (DWDM) Networks", RFC 7698, November 2015. [RFC8340] M. Bjorklund,"Network Configuration Access Control Model",L. Berger, Ed., "YANG Tree Diagrams", RFC8341,8340, March 2018. [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, "Network Management Datastore Architecture (NMDA)", RFC 8342, March 2018. [RFC8345] A. Clemm, et al, "A YANG Data Model for Network Topologies", RFC 8345, March 2018. [TE-TOPO] X. Liu, et al., "YANG Data Model for TE Topologies", work in progress: draft-ietf-teas-yang-te-topo. [RFC8453] Ceccarelli, D. and Y. Lee, "Framework for Abstraction and Control of Traffic Engineered Networks", RFC 8453, August 2018. [WSON-Topo] Y. Lee, Ed., "A Yang Data Model for WSON Optical Networks", draft-ietf-ccamp-wson-yang-13, work in progress. [L0-Types] Y. Lee, Ed., "A YANG Data Model for Layer 0 Types", draft-ietf-ccamp-layer0-types, work in progress. [G.807] "Draft new Recommendation ITU-T G.807 (ex G.media)", ITU-T Recommendation G.807, work in progress. [G.709] "Interfaces for the Optical Transport Network (OTN)", ITU-T Recommendation G.709, June 2016. [G.694.1] "Spectral grids for WDM applications: DWDM frequency grid", ITU-T Recommendation G.694.1, February 2012. [G.959.1] "Optical transport network physical layer interfaces", ITU-T Recommendation G.959.1, February 2012. [G.872] "Architecture of optical transport networks", ITU-T Recommendation G.872, January 2017. 9. Contributors Jonas MartenssonAcroRISE Email: jonas.martensson@ri.se Aihua Guo Huawei Technologies Email: aguo@futurewei.com Authors' Addresses Young LeeHuaweiFuturewei Technologies Email:leeyoung@huawei.comyounglee.tx@gmail.com Haomian Zheng Huawei Technologies Email: zhenghaomian@huawei.com Italo Busi Huawei Technologies Email: Italo.Busi@huawei.com Nicola Sambo Scuola Superiore Sant'Anna Email: nicosambo@gmail.com Victor Lopez Telefonica Email: victor.lopezalvarez@telefonica.com G. Galimberti Cisco Email: ggalimbe@cisco.com Giovanni Martinelli Cisco Email: giomarti@cisco.com AUGE Jean Luc Orange Email: jeanluc.auge@orange.com LE ROUZIC Esther Orange Email: esther.lerouzic@orange.com Julien Meuric Orange Email: julien.meuric@orange.com Dieter Beller Nokia Email: dieter.beller@nokia.com Sergio Belotti Nokia Email: Sergio.belotti@nokia.com Griseri Enrico Nokia Email: enrico.griseri@nokia.com Gert Grammel Juniper Email: ggrammel@juniper.net