idnits 2.17.1 draft-dharini-netmod-g-698-2-yang-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([ITU.G874.1], [ITU.G698.2]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 566 has weird spacing: '...nCodeId uin...' == Line 567 has weird spacing: '...odeType uint8...' == Line 573 has weird spacing: '...nCodeId uint...' == Line 574 has weird spacing: '...odeType uint8...' == Line 590 has weird spacing: '...odeType uint8...' == (1 more instance...) == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 6, 2015) is 3217 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'ITU-T G.7710' is mentioned on line 124, but not defined == Missing Reference: 'RFC6241' is mentioned on line 828, but not defined == Missing Reference: 'RFC6242' is mentioned on line 830, but not defined == Missing Reference: 'RFC6536' is mentioned on line 830, but not defined ** Obsolete undefined reference: RFC 6536 (Obsoleted by RFC 8341) == Missing Reference: 'RFC3688' is mentioned on line 838, but not defined == Missing Reference: 'RFC6020' is mentioned on line 851, but not defined == Unused Reference: 'RFC2863' is defined on line 896, but no explicit reference was found in the text == Unused Reference: 'RFC2578' is defined on line 902, but no explicit reference was found in the text == Unused Reference: 'RFC2579' is defined on line 906, but no explicit reference was found in the text == Unused Reference: 'RFC2580' is defined on line 910, but no explicit reference was found in the text == Unused Reference: 'RFC6205' is defined on line 918, but no explicit reference was found in the text == Unused Reference: 'ITU.G709' is defined on line 928, but no explicit reference was found in the text == Unused Reference: 'ITU.G959.1' is defined on line 955, but no explicit reference was found in the text == Unused Reference: 'ITU.G826' is defined on line 960, but no explicit reference was found in the text == Unused Reference: 'ITU.G8201' is defined on line 966, but no explicit reference was found in the text == Unused Reference: 'ITU.G7710' is defined on line 977, but no explicit reference was found in the text == Unused Reference: 'RFC2629' is defined on line 988, but no explicit reference was found in the text == Unused Reference: 'RFC4181' is defined on line 991, but no explicit reference was found in the text == Unused Reference: 'I-D.kunze-g-698-2-management-control-framework' is defined on line 994, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.G698.2' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.G709' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.G872' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.G798' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.G874' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.G874.1' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.G959.1' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.G826' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.G8201' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.G694.1' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.G7710' -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) == Outdated reference: A later version (-02) exists of draft-kunze-g-698-2-management-control-framework-00 Summary: 2 errors (**), 0 flaws (~~), 28 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force G.Galimberti, Ed. 3 Internet-Draft Cisco 4 Intended status: Standards Track R.Kunze, Ed. 5 Expires: January 7, 2016 Deutsche Telekom 6 K. Lam, Ed. 7 Alcatel-Lucent 8 D. Hiremagalur, Ed. 9 G. G.Grammel, Ed. 10 Juniper 11 L.Fang, Ed. 12 G.Ratterree, Ed. 13 Microsoft 14 July 6, 2015 16 A YANG model to manage the optical interface parameters of "G.698.2 17 single channel" in DWDM applications 18 draft-dharini-netmod-g-698-2-yang-04 20 Abstract 22 This memo defines a Yang model that translates the SNMP mib module 23 defined in draft-galikunze-ccamp-g-698-2-snmp-mib for managing single 24 channel optical interface parameters of DWDM applications, using the 25 approach specified in G.698.2. This model is to support the optical 26 parameters specified in ITU-T G.698.2 [ITU.G698.2] and application 27 identifiers specified in ITU-T G.874.1 [ITU.G874.1] . Note that 28 G.874.1 encompasses vendor-specific codes, which if used would make 29 the interface a single vendor IaDI and could still be managed. 31 The Yang model defined in this memo can be used for Optical 32 Parameters monitoring and/or configuration of the endpoints of the 33 multi-vendor IaDI based on the Black Link approach. 35 Copyright Notice 37 Copyright (c) 2014 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 Status of This Memo 42 This Internet-Draft is submitted in full conformance with the 43 provisions of BCP 78 and BCP 79. 45 Internet-Drafts are working documents of the Internet Engineering 46 Task Force (IETF). Note that other groups may also distribute 47 working documents as Internet-Drafts. The list of current Internet- 48 Drafts is at http://datatracker.ietf.org/drafts/current/. 50 Internet-Drafts are draft documents valid for a maximum of six months 51 and may be updated, replaced, or obsoleted by other documents at any 52 time. It is inappropriate to use Internet-Drafts as reference 53 material or to cite them other than as "work in progress." 55 This Internet-Draft will expire on January 7, 2016. 57 Copyright Notice 59 Copyright (c) 2015 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents 64 (http://trustee.ietf.org/license-info) in effect on the date of 65 publication of this document. Please review these documents 66 carefully, as they describe your rights and restrictions with respect 67 to this document. Code Components extracted from this document must 68 include Simplified BSD License text as described in Section 4.e of 69 the Trust Legal Provisions and are provided without warranty as 70 described in the Simplified BSD License. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 75 2. The Internet-Standard Management Framework . . . . . . . . . 4 76 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 77 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 78 4.1. Optical Parameters Description . . . . . . . . . . . . . 5 79 4.1.1. Rs-Ss Configuration . . . . . . . . . . . . . . . . . 6 80 4.1.2. Table of Application Codes . . . . . . . . . . . . . 7 81 4.2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 7 82 4.3. Optical Interface for G.698.2 . . . . . . . . . . . . . . 14 83 5. Structure of the Yang Module . . . . . . . . . . . . . . . . 14 84 6. Yang Module . . . . . . . . . . . . . . . . . . . . . . . . . 15 85 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 86 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 87 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 88 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20 89 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 90 11.1. Normative References . . . . . . . . . . . . . . . . . . 21 91 11.2. Informative References . . . . . . . . . . . . . . . . . 23 92 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 24 93 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 24 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 96 1. Introduction 98 This memo defines a Yang model that translates the SNMP mib module 99 defined in draft-galikunze-ccamp-g-698-2-snmp-mib for managing single 100 channel optical interface parameters of DWDM applications, using the 101 approach specified in G.698.2. This model is to support the optical 102 parameters specified in ITU-T G.698.2 [ITU.G698.2], application 103 identifiers specified in ITU-T G.874.1 [ITU.G874.1] and the Optical 104 Power at Transmitter and Receiver side. Note that G.874.1 105 encompasses vendor-specific codes, which if used would make the 106 interface a single vendor IaDI and could still be managed.` 108 The Black Link approach allows supporting an optical transmitter/ 109 receiver pair of one vendor to inject an optical tributary signal and 110 run it over an optical network composed of amplifiers, filters, add- 111 drop multiplexers from a different vendor. In the OTN architecture, 112 the 'black-link' represents a pre-certified network media channel 113 conforming to G.698.2 specifications at the S and R reference points. 115 [Editor's note: In G.698.2 this corresponds to the optical path from 116 point S to R; network media channel is also used and explained in 117 draft-ietf-ccamp-flexi-grid-fwk-02] 119 Management will be performed at the edges of the network media 120 channel (i.e., at the transmitters and receivers attached to the S 121 and R reference points respectively) for the relevant parameters 122 specified in G.698.2 [ITU.G698.2], G.798 [ITU.G798], G.874 123 [ITU.G874], and the performance parameters specified in G.7710/Y.1701 124 [ITU-T G.7710] and G.874.1 [ITU.G874.1]. 126 G.698.2 [ITU.G698.2] is primarily intended for metro applications 127 that include optical amplifiers. Applications are defined in G.698.2 128 [ITU.G698.2] using optical interface parameters at the single-channel 129 connection points between optical transmitters and the optical 130 multiplexer, as well as between optical receivers and the optical 131 demultiplexer in the DWDM system. This Recommendation uses a 132 methodology which does not explicitly specify the details of the 133 optical network between reference point Ss and Rs, e.g., the passive 134 and active elements or details of the design. The Recommendation 135 currently includes unidirectional DWDM applications at 2.5 and 10 136 Gbit/s (with 100 GHz and 50 GHz channel frequency spacing). Work is 137 still under way for 40 and 100 Gbit/s interfaces. There is 138 possibility for extensions to a lower channel frequency spacing. 139 This document specifically refers to the "application code" defined 140 in the G.698.2 [ITU.G698.2] and included in the Application 141 Identifier defined in G.874.1 [ITU.G874.1] and G.872 [ITU.G872], plus 142 a few optical parameters not included in the G.698.2 application code 143 specification. 145 This draft refers and supports the draft-kunze-g-698-2-management- 146 control-framework 148 The building of a yang model describing the optical parameters 149 defined in G.698.2 [ITU.G698.2], and reflected in G.874.1 150 [ITU.G874.1], allows the different vendors and operator to retrieve, 151 provision and exchange information across the G.698.2 multi-vendor 152 IaDI in a standardized way. In addition to the parameters specified 153 in ITU recommendations the Yang models support also the "vendor 154 specifica application identifier", the Tx and Rx power at the Ss and 155 Rs points and the channel frequency. 157 The Yang Model, reporting the Optical parameters and their values, 158 characterizes the features and the performances of the optical 159 components and allow a reliable black link design in case of multi 160 vendor optical networks. 162 Although RFC 3591 [RFC3591], which draft-galikunze-ccamp-g-698-2- 163 snmp-mib is extending, describes and defines the SNMP MIB of a number 164 of key optical parameters, alarms and Performance Monitoring, as this 165 RFC is over a decade old, it is primarily pre-OTN, and a more 166 complete and up-to-date description of optical parameters and 167 processes can be found in the relevant ITU-T Recommendations. The 168 same considerations can be applied to the RFC 4054 [RFC4054]. 170 2. The Internet-Standard Management Framework 172 For a detailed overview of the documents that describe the current 173 Internet-Standard Management Framework, please refer to section 7 of 174 RFC 3410 [RFC3410]. 176 This memo specifies a Yang model for optical interfaces. 178 3. Conventions 180 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 181 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 182 document are to be interpreted as described in RFC 2119 [RFC2119] In 183 the description of OIDs the convention: Set (S) Get (G) and Trap (T) 184 conventions will describe the action allowed by the parameter. 186 4. Overview 187 Figure 1 shows a set of reference points, for the linear "black link" 188 approach, for single-channel connection (Ss and Rs) between 189 transmitters (Tx) and receivers (Rx). Here the DWDM network elements 190 include an OM and an OD (which are used as a pair with the opposing 191 element), one or more optical amplifiers and may also include one or 192 more OADMs. 194 +-------------------------------------------------+ 195 Ss | DWDM Network Elements | Rs 196 +--+ | | | \ / | | | +--+ 197 Tx L1--|->| \ +------+ +------+ / |--|-->Rx L1 198 +---+ | | | | | +------+ | | | | | +--+ 199 +---+ | | | | | | | | | | | | +--+ 200 Tx L2--|->| OM |-->|------|->| OADM |--|------|->| OD |--|-->Rx L2 201 +---+ | | | | | | | | | | | | +--+ 202 +---+ | | | | | +------+ | | | | | +--+ 203 Tx L3--|->| / | DWDM | | ^ | DWDM | \ |--|-->Rx L3 204 +---+ | | / | Link +----|--|----+ Link | \ | | +--+ 205 +-----------+ | | +----------+ 206 +--+ +--+ 207 | | 208 Rs v | Ss 209 +-----+ +-----+ 210 |RxLx | |TxLx | 211 +-----+ +-----+ 212 Ss = reference point at the DWDM network element tributary output 213 Rs = reference point at the DWDM network element tributary input 214 Lx = Lambda x 215 OM = Optical Mux 216 OD = Optical Demux 217 OADM = Optical Add Drop Mux 219 from Fig. 5.1/G.698.2 221 Figure 1: Linear Black Link approach 223 G.698.2 [ITU.G698.2] defines also Ring "Black Link" approach 224 configurations [Fig. 5.2/G.698.2] and Linear "black link" approach 225 for Bidirectional applications[Fig. 5.3/G.698.2] 227 4.1. Optical Parameters Description 229 The G.698.2 pre-certified network media channels are managed at the 230 edges, i.e. at the transmitters (Tx) and receivers (Rx) attached to 231 the S and R reference points respectively. The set of parameters 232 that could be managed are specified in G.698.2 [ITU.G698.2] section 233 5.3 referring the "application code" notation 235 The definitions of the optical parameters are provided below to 236 increase the readability of the document, where the definition is 237 ended by (R) the parameter can be retrieve with a read, when (W) it 238 can be provisioned by a write, (R,W) can be either read or written. 240 4.1.1. Rs-Ss Configuration 242 The Rs-Ss configuration table allows configuration of Central 243 Frequency, Power and Application codes as described in [ITU.G698.2] 244 and G.694.1 [ITU.G694.1] 245 This parameter report the current Transceiver Output power, it can be 246 either a setting and measured value (G, S). 248 Central frequency (see G.694.1 Table 1) (see G.694.1 Table 1): 249 This parameter indicates the Central frequency value that Ss and 250 Rs will be set to work (in THz). See the details in Section 6/ 251 G.694.1 (G, S). 253 Single-channel application codes(see G.698.2): 254 This parameter indicates the transceiver application code at Ss 255 and Rs as defined in [ITU.G698.2] Chapter 5.4 - this parameter can 256 be called Optical Interface Identifier OII as per [draft- 257 martinelli-wson-interface-class](G). 259 Number of Single-channel application codes Supported 260 This parameter indicates the number of Single-channel application 261 codes supported by this interface (G). 263 Current Laser Output power: 264 This parameter report the current Transceiver Output power, it can 265 be either a setting and measured value (G, S). 267 Current Laser Input power: 268 This parameter report the current Transceiver Input power (G). 270 +---------------------------------------------+---------+-----------+ 271 | PARAMETERS | Get/Set | Reference | 272 +---------------------------------------------+---------+-----------+ 273 | Central frequency Value | G,S | G.694.1 | 274 | | | S.6 | 275 | Single-channel application codes | G | G.698.2 | 276 | | | S.5.3 | 277 | Number of Single-channel application codes | G | N.A. | 278 | Supported | | | 279 | Current Output Power | G,S | N.A. | 280 | Current Input Power | G | N.A. | 281 +---------------------------------------------+---------+-----------+ 283 Table 1: Rs-Ss Configuration 285 4.1.2. Table of Application Codes 287 This table has a list of Application codes supported by this 288 interface at point R are defined in G.698.2. 290 Application code Identifier: 291 The Identifier for the Application code. 293 Application code Type: 294 This parameter indicates the transceiver type of application code 295 at Ss and Rs as defined in [ITU.G874.1], that is used by this 296 interface Standard = 0, PROPRIETARY = 1 297 The first 6 octets of the printable string will be the OUI 298 (organizationally unique identifier) assigned to the vendor 299 whose implementation generated the Application Identifier Code. 301 Application code Length: 302 The number of octets in the Application Code. 304 Application code: 305 This is the application code that is defined in G.698.2 or the 306 vendor generated code which has the OUI. 308 4.2. Use Cases 310 The use cases described below are assuming that power monitoring 311 functions are available in the ingress and egress network element of 312 the DWDM network, respectively. By performing link property 313 correlation it would be beneficial to include the current transmit 314 power value at reference point Ss and the current received power 315 value at reference point Rs. For example if the Client transmitter 316 power (OXC1) has a value of 0dBm and the ROADM interface measured 317 power (at OLS1) is -6dBm the fiber patch cord connecting the two 318 nodes may be pinched or the connectors are dirty. More, the 319 interface characteristics can be used by the OLS network Control 320 Plane in order to check the Optical Channels feasibility. Finally 321 the OXC1 transceivers parameters (Application Code) can be shared 322 with OXC2 using the LMP protocol to verify the Transceivers 323 compatibility. The actual route selection of a specific wavelength 324 within the allowed set is outside the scope of LMP. In GMPLS, the 325 parameter selection (e.g. central frequency) is performed by RSVP-TE. 327 G.698.2 defines a single channel optical interface for DWDM systems 328 that allows interconnecting network-external optical transponders 329 across a DWDM network. The optical transponders are considered to be 330 external to the DWDM network. This so-called 'black link' approach 331 illustrated in Figure 5-1 of G.698.2 and a copy of this figure is 332 provided below. The single channel fiber link between the Ss/Rs 333 reference points and the ingress/egress port of the network element 334 on the domain boundary of the DWDM network (DWDM border NE) is called 335 access link in this contribution. Based on the definition in G.698.2 336 it is considered to be part of the DWDM network. The access link 337 typically is realized as a passive fiber link that has a specific 338 optical attenuation (insertion loss). As the access link is an 339 integral part of the DWDM network, it is desirable to monitor its 340 attenuation. Therefore, it is useful to detect an increase of the 341 access link attenuation, for example, when the access link fiber has 342 been disconnected and reconnected (maintenance) and a bad patch panel 343 connection (connector) resulted in a significantly higher access link 344 attenuation (loss of signal in the extreme case of an open connector 345 or a fiber cut). In the following section, two use cases are 346 presented and discussed: 348 1) pure access link monitoring 349 2) access link monitoring with a power control loop 351 These use cases require a power monitor as described in G.697 (see 352 section 6.1.2), that is capable to measure the optical power of the 353 incoming or outgoing single channel signal. The use case where a 354 power control loop is in place could even be used to compensate an 355 increased attenuation as long as the optical transmitter can still be 356 operated within its output power range defined by its application 357 code. 359 Figure 2 Access Link Power Monitoring 361 +--------------------------+ 362 | P(in) = P(Tx) - a(Tx) | 363 | ___ | 364 +----------+ | \ / Power Monitor | 365 | | P(Tx) | V | 366 | +----+ | Ss //\\ | | |\ | 367 | | TX |----|-----\\//------------------->| \ | 368 | +----+ | Access Link (AL-T) | . | | | 369 | | attenuation a(Tx) | . | |==============> 370 | | | . | | | 371 | External | | --->| / | 372 | Optical | | |/ | 373 |Transpond.| | P(out) | 374 | | | ___ | 375 | | | \ / Power Monitor | 376 | | P(Rx) | V | 377 | +----+ | Rs //\\ | | |\ | 378 | | RX |<---|-----\\//--------------------| \ | 379 | +----+ | Access Link (AL-R) | . | | | 380 | | Attenuation a(Rx) | . | |<============== 381 +----------+ | . | | | 382 | <---| / | 383 P(Rx) = P(out) - a(Rx) | |/ | 384 | | 385 | ROADM | 386 +--------------------------+ 388 - For AL-T monitoring: P(Tx) and a(Tx) must be known 389 - For AL-R monitoring: P(RX) and a(Rx) must be known 391 An alarm shall be raised if P(in) or P(Rx) drops below a 392 configured threshold (t [dB]): 393 - P(in) < P(Tx) - a(Tx) - t (Tx direction) 394 - P(Rx) < P(out) - a(Rx) - t (Rx direction) 395 - a(Tx) =| a(Rx) 397 Figure 2: Extended LMP Model 399 Pure Access Link (AL) Monitoring Use Case 401 Figure 4 illustrates the access link monitoring use case and the 402 different physical properties involved that are defined below: 404 - Ss, Rs: G.698.2 reference points 405 - P(Tx): current optical output power of transmitter Tx 406 - a(Tx): access link attenuation in Tx direction (external 407 transponder point of view) 408 - P(in): measured current optical input power at the input port 409 of border DWDM NE 410 - t: user defined threshold (tolerance) 411 - P(out): measured current optical output power at the output port 412 of border DWDM NE 413 - a(Rx): access link attenuation in Rx direction (external 414 transponder point of view) 415 - P(Rx): current optical input power of receiver Rx 417 Assumptions: 418 - The access link attenuation in both directions (a(Tx), a(Rx)) 419 is known or can be determined as part of the commissioning 420 process. Typically, both values are the same. 421 - A threshold value t has been configured by the operator. This 422 should also be done during commissioning. 423 - A control plane protocol (e.g. this draft) is in place that allows 424 to periodically send the optical power values P(Tx) and P(Rx) 425 to the control plane protocol instance on the DWDM border NE. 426 This is llustrated in Figure 3. 427 - The DWDM border NE is capable to periodically measure the optical 428 power Pin and Pout as defined in G.697 by power monitoring points 429 depicted as yellow triangles in the figures below. 431 AL monitoring process: 432 - Tx direction: the measured optical input power Pin is compared 433 with the expected optical input power P(Tx) - a(Tx). If the 434 measured optical input power P(in) drops below the value 435 (P(Tx) - a(Tx) - t) a low power alarm shall be raised indicating 436 that the access link attenuation has exceeded a(Tx) + t. 437 - Rx direction: the measured optical input power P(Rx) is 438 compared with the expected optical input power P(out) - a(Rx). 439 If the measured optical input power P(Rx) drops below the value 440 (P(out) - a(Rx) - t) a 441 low power alarm shall be raised indicating that the access link 442 attenuation has exceeded a(Rx) + t. 444 Figure 3 Use case 1: Access Link power monitoring 446 +----------+ +--------------------------+ 447 | +------+ | P(Tx), P(Rx) | +-------+ | 448 | | | | =================> | | | | 449 | | LMP | | P(in), P(out) | | LMP | | 450 | | | | <================= | | | | 451 | +------+ | | +-------+ | 452 | | | | 453 | | | P(in) - P(Tx) - a(Tx) | 454 | | | ___ | 455 | | | \ / Power Monitor | 456 | | P(Tx) | V | 457 | +----+ | Ss //\\ | | |\ | 458 | | TX |----|-----\\//------------------->| \ | 459 | +----+ | Access Link (AL-T) | . | | | 460 | | attenuation a(Tx) | . | |==============> 461 | | | . | | | 462 | External | | --->| / | 463 | Optical | | |/ | 464 |Transpond.| | P(out) | 465 | | | ___ | 466 | | | \ / Power Monitor | 467 | | P(Rx) | V | 468 | +----+ | Rs //\\ | | |\ | 469 | | RX |<---|-----\\//--------------------| \ | 470 | +----+ | Access Link (AL-R) | . | | | 471 | | Attenuation a(Rx) | . | |<============== 472 +----------+ | . | | | 473 | <---| / | 474 P(Rx) = P(out) - a(Rx) | |/ | 475 | | 476 | ROADM | 477 +--------------------------+ 479 - For AL-T monitoring: P(Tx) and a(Tx) must be known 480 - For AL-R monitoring: P(RX) and a(Rx) must be known 482 An alarm shall be raised if P(in) or P(Rx) drops below a 483 configured threshold (t [dB]): 484 - P(in) < P(Tx) - a(Tx) - t (Tx direction) 485 - P(Rx) < P(out) - a(Rx) - t (Rx direction) 486 - a(Tx) = a(Rx) 488 Figure 3: Extended LMP Model 490 Power Control Loop Use Case 492 This use case is based on the access link monitoring use case as 493 described above. In addition, the border NE is running a power 494 control application that is capable to control the optical output 495 power of the single channel tributary signal at the output port 496 of the border DWDM NE (towards the external receiver Rx) and the 497 optical output power of the single channel tributary signal at 498 the external transmitter Tx within their known operating range. 499 The time scale of this control loop is typically relatively slow 500 (e.g. some 10s or minutes) because the access link attenuation 501 is not expected to vary much over time (the attenuation only 502 changes when re-cabling occurs). 503 From a data plane perspective, this use case does not require 504 additional data plane extensions. It does only require a protocol 505 extension in the control plane (e.g. this LMP draft) that allows 506 the power control application residing in the DWDM border NE to 507 modify the optical output power of the DWDM domain-external 508 transmitter Tx within the range of the currently used application 509 code. Figure 5 below illustrates this use case utilizing the LMP 510 protocol with extensions defined in this draft. 512 Figure 4 Use case 2: Power Control Loop 514 +----------+ +--------------------------+ 515 | +------+ | P(Tx),P(Rx),Set(Pout) | +-------+ +--------+ | 516 | | | | ====================> | | | | Power | | 517 | | LMP | | P(in),P(out),Set(PTx) | | LMP | |Control | | 518 | | | | <==================== | | | | Loop | | 519 | +------+ | | +-------+ +--------+ | 520 | | | | | 521 | +------+ | | P(in) = P(Tx) - a(Tx) | 522 | |C.Loop| | | ___ | 523 | +------+ | | \ / Power Monitor | 524 | | | P(Tx) | V | 525 | +------+ | Ss //\\ | | |\ | 526 | | TX |>---|-----\\//---------------------->| \ | 527 | +------+ | Access Link (AL-T) | . | | | 528 | VOA(Tx) | attenuation a(Tx) | . | |==============> 529 | | | . | | | 530 | External | | --->| / | 531 | Optical | | |/ | 532 |Transpond.| | P(out) | 533 | | | ___ | 534 | | | \ / Power Monitor | 535 | | P(Rx) | V | 536 | +----+ | Rs //\\ | | VOA(out) |\ | 537 | | RX |<---|-----\\//---------------------<|-------| \ | 538 | +----+ | Access Link (AL-R) | . | | | 539 | | attenuation a(Rx) | . | |<======= 540 +----------+ | VOA(out) | | | 541 | <--<|-------| / | 542 P(Rx) = P(out) - a(Rx) | |/ | 543 | | 544 | ROADM | 545 +--------------------------+ 547 The Power Control Loops in Transponder and ROADM regulate 548 the Variable Optical Attenuators (VOA) to adjust the 549 proper power in base of the ROADM and Receiver 550 caracteristics and the Access Link attenuation 552 Figure 4: Extended LMP Model 554 4.3. Optical Interface for G.698.2 556 The ietf-opt-if-g698-2 is an augment to the ietf-interface. It 557 allows the user to set the application code/vendor transceiver class/ 558 Central frequency and the output power. The module can also be used 559 to get the list of supported application codes/transceiver class and 560 also the Central frequency/output power/input power of the interface. 562 module: ietf-opt-if-g698-2 563 augment /if:interfaces/if:interface: 564 +--rw optIfOChRsSs 565 +--rw ifCurrentApplicationCode 566 | +--rw applicationCodeId uint8 567 | +--rw applicationCodeType uint8 568 | +--rw applicationCodeLength uint8 569 | +--rw applicationCode? string 570 +--ro ifSupportedApplicationCodes 571 | +--ro numberApplicationCodesSupported? uint32 572 | +--ro applicationCodesList* [applicationCodeId] 573 | +--ro applicationCodeId uint8 574 | +--rw applicationCodeType uint8 575 | +--rw applicationCodeLength uint8 576 | +--ro applicationCode? string 577 +--rw outputPower? int32 578 +--ro inputPower? int32 579 +--rw centralFrequency? uint32 581 notifications: 582 +---n optIfOChCentralFrequencyChange 583 | +--ro if-name? leafref 584 | +--ro newCentralFrequency 585 | +--ro centralFrequency? uint32 586 +---n optIfOChApplicationCodeChange 587 | +--ro if-name? leafref 588 | +--ro newApplicationCode 589 | +--ro applicationCodeId? uint8 590 | +--rw applicationCodeType uint8 591 | +--rw applicationCodeLength uint8 592 | +--ro applicationCode? string 594 5. Structure of the Yang Module 596 ietf-opt-if-g698-2 is a top level model for the support of this 597 feature. 599 6. Yang Module 601 The ietf-opt-if-g698-2 is defined as an extension to ietf interfaces. 603 file "ietf-opt-if-g698-2.yang" 605 module ietf-opt-if-g698-2 { 606 namespace "urn:ietf:params:xml:ns:yang:ietf-opt-if-g698-2"; 607 prefix ietf-opt-if-g698-2; 609 import ietf-interfaces { 610 prefix if; 611 } 613 organization 614 "IETF NETMOD (NETCONF Data Modelling Language) 615 Working Group"; 617 contact 618 "WG Web: 619 WG List: 621 WG Chair: Thomas Nadeau 622 624 WG Chair: Juergen Schoenwaelder 625 627 Editor: Dharini Hiremagalur 628 "; 630 description 631 "This module contains a collection of YANG definitions for 632 configuring Optical interfaces. 634 Copyright (c) 2013 IETF Trust and the persons identified 635 as authors of the code. All rights reserved. 637 Redistribution and use in source and binary forms, with or 638 without modification, is permitted pursuant to, and 639 subject to the license terms contained in, the Simplified 640 BSD License set forth in Section 4.c of the IETF Trust's 641 Legal Provisions Relating to IETF Documents 642 (http://trustee.ietf.org/license-info)."; 644 revision "2015-06-24" { 645 description 646 "Revision 4.0"; 648 reference 649 " draft-dharini-netmod-dwdm-if-yang 3.0"; 650 } 651 revision "2015-02-24" { 652 description 653 "Revision 3.0"; 655 reference 656 " draft-dharini-netmod-dwdm-if-yang 3.0"; 657 } 658 revision "2014-11-10" { 659 description 660 "Revision 2.0"; 661 reference 662 " "; 663 } 664 revision "2014-10-14" { 665 description 666 "Revision 1.0"; 667 reference 668 " "; 669 } 670 revision "2014-05-10" { 671 description 672 "Initial revision."; 673 reference 674 "RFC XXXX: A YANG Data Model for Optical 675 Management of an Interface for g.698.2 676 support"; 677 } 679 grouping optIfOChApplicationCode { 680 description "Application code entity."; 681 leaf applicationCodeId { 682 type uint8 { 683 range "1..255"; 684 } 685 description 686 "Id for the Application code"; 687 } 688 leaf applicationCodeType { 689 type uint8 { 690 range "0..1"; 691 } 692 description 693 "Type for the Application code 694 0 - Standard, 1 - Proprietory 695 When the Type is Proprietory, then the 696 first 6 octets of the applicationCode 697 will be the OUI (organizationally unique 698 identifier)"; 700 } 701 leaf applicationCodeLength { 702 type uint8 { 703 range "1..255"; 704 } 705 description 706 "Number of octets in the Application code"; 708 } 709 leaf applicationCode { 710 type string { 711 length "1..255"; 712 } 713 description "This parameter indicates the 714 transceiver application code at Ss and Rs as 715 defined in [ITU.G698.2] Chapter 5.3, that 716 is/should be used by this interface. 717 The optIfOChApplicationsCodeList has all the 718 application codes supported by this 719 interface."; 721 } 722 } 724 grouping optIfOChApplicationCodeList { 725 description "List of Application codes group."; 726 leaf numberApplicationCodesSupported { 727 type uint32; 728 description "Number of Application codes 729 supported by this interface"; 730 } 731 list applicationCodeList { 732 key "applicationCodeId"; 733 description "List of the application codes"; 734 uses optIfOChApplicationCode; 735 } 736 } 738 grouping optIfOChPower { 739 description "Interface optical Power"; 740 leaf outputPower { 741 type int32; 742 units ".01dbm"; 743 description "The output power for this interface in 744 .01 dBm."; 745 } 747 leaf inputPower { 748 type int32; 749 units ".01dbm"; 750 config false; 751 description "The current input power of this 752 interface"; 753 } 754 } 756 grouping optIfOChCentralFrequency { 757 description "Interface Central Frequency"; 758 leaf centralFrequency { 759 type uint32; 760 description "This parameter indicate This parameter 761 indicates the frequency of this interface "; 763 } 764 } 766 notification optIfOChCentralFrequencyChange { 767 description "A change of Central Frequency has been 768 detected."; 769 leaf "if-name" { 770 type leafref { 771 path "/if:interfaces/if:interface/if:name"; 772 } 773 description "Interface name"; 774 } 775 container newCentralFrequency { 776 description "The new Central Frequency of the 777 interface"; 778 uses optIfOChCentralFrequency; 779 } 780 } 782 notification optIfOChApplicationCodeChange { 783 description "A change of Application code has been 784 detected."; 785 leaf "if-name" { 786 type leafref { 787 path "/if:interfaces/if:interface/if:name"; 788 } 789 description "Interface name"; 790 } 791 container newApplicationCode { 792 description "The new application code for the 793 interface"; 794 uses optIfOChApplicationCode; 795 } 796 } 798 augment "/if:interfaces/if:interface" { 799 description "Parameters for an optical interface"; 800 container optIfOChRsSs { 801 description "RsSs path configuration for an interface"; 802 container ifCurrentApplicationCode { 803 description "Current Application code of the 804 interface"; 805 uses optIfOChApplicationCode; 806 } 808 container ifSupportedApplicationCodes { 809 config false; 810 description "Supported Application codes of 811 the interface"; 812 uses optIfOChApplicationCodeList; 813 } 815 uses optIfOChPower; 817 uses optIfOChCentralFrequency; 819 } 820 } 821 } 823 825 7. Security Considerations 827 The YANG module defined in this memo is designed to be accessed via 828 the NETCONF protocol [RFC6241]. he lowest NETCONF layer is the secure 829 transport layer and the mandatory-to-implement secure transport is 830 SSH [RFC6242]. The NETCONF access control model [RFC6536] provides 831 the means to restrict access for particular NETCONF users to a pre- 832 configured subset of all available NETCONF protocol operation and 833 content. 835 8. IANA Considerations 837 This document registers a URI in the IETF XML registry [RFC3688]. 838 Following the format in [RFC3688], the following registration is 839 requested to be made: 841 URI: urn:ietf:params:xml:ns:yang:ietf-interfaces:ietf-opt-if-g698-2 843 Registrant Contact: The IESG. 845 XML: N/A, the requested URI is an XML namespace. 847 This document registers a YANG module in the YANG Module Names 848 registry [RFC6020]. 850 This document registers a YANG module in the YANG Module Names 851 registry [RFC6020]. 853 prefix: ietf-opt-if-g698-2 reference: RFC XXXX 855 9. Acknowledgements 857 Gert Grammel is partly funded by European Union Seventh Framework 858 Programme under grant agreement 318514 CONTENT. 860 10. Contributors 861 Dean Bogdanovic 862 Juniper Networks 863 Westford 864 U.S.A. 865 email deanb@juniper.net 867 Bernd Zeuner 868 Deutsche Telekom 869 Darmstadt 870 Germany 871 email B.Zeuner@telekom.de 873 Arnold Mattheus 874 Deutsche Telekom 875 Darmstadt 876 Germany 877 email a.mattheus@telekom.de 879 Manuel Paul 880 Deutsche Telekom 881 Berlin 882 Germany 883 email Manuel.Paul@telekom.de 885 Walid Wakim 886 Cisco 887 9501 Technology Blvd 888 ROSEMONT, ILLINOIS 60018 889 UNITED STATES 890 email wwakim@cisco.com 892 11. References 894 11.1. Normative References 896 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group 897 MIB", RFC 2863, June 2000. 899 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 900 Requirement Levels", BCP 14, RFC 2119, March 1997. 902 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 903 Schoenwaelder, Ed., "Structure of Management Information 904 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 906 [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. 907 Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD 908 58, RFC 2579, April 1999. 910 [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, 911 "Conformance Statements for SMIv2", STD 58, RFC 2580, 912 April 1999. 914 [RFC3591] Lam, H-K., Stewart, M., and A. Huynh, "Definitions of 915 Managed Objects for the Optical Interface Type", RFC 3591, 916 September 2003. 918 [RFC6205] Otani, T. and D. Li, "Generalized Labels for Lambda- 919 Switch-Capable (LSC) Label Switching Routers", RFC 6205, 920 March 2011. 922 [ITU.G698.2] 923 International Telecommunications Union, "Amplified 924 multichannel dense wavelength division multiplexing 925 applications with single channel optical interfaces", 926 ITU-T Recommendation G.698.2, November 2009. 928 [ITU.G709] 929 International Telecommunications Union, "Interface for the 930 Optical Transport Network (OTN)", ITU-T Recommendation 931 G.709, March 2003. 933 [ITU.G872] 934 International Telecommunications Union, "Architecture of 935 optical transport networks", ITU-T Recommendation G.872, 936 November 2001. 938 [ITU.G798] 939 International Telecommunications Union, "Characteristics 940 of optical transport network hierarchy equipment 941 functional blocks", ITU-T Recommendation G.798, October 942 2010. 944 [ITU.G874] 945 International Telecommunications Union, "Management 946 aspects of optical transport network elements", ITU-T 947 Recommendation G.874, July 2010. 949 [ITU.G874.1] 950 International Telecommunications Union, "Optical transport 951 network (OTN): Protocol-neutral management information 952 model for the network element view", ITU-T Recommendation 953 G.874.1, January 2002. 955 [ITU.G959.1] 956 International Telecommunications Union, "Optical transport 957 network physical layer interfaces", ITU-T Recommendation 958 G.959.1, November 2009. 960 [ITU.G826] 961 International Telecommunications Union, "End-to-end error 962 performance parameters and objectives for international, 963 constant bit-rate digital paths and connections", ITU-T 964 Recommendation G.826, November 2009. 966 [ITU.G8201] 967 International Telecommunications Union, "Error performance 968 parameters and objectives for multi-operator international 969 paths within the Optical Transport Network (OTN)", ITU-T 970 Recommendation G.8201, April 2011. 972 [ITU.G694.1] 973 International Telecommunications Union, "Spectral grids 974 for WDM applications: DWDM frequency grid", ITU-T 975 Recommendation G.694.1, June 2002. 977 [ITU.G7710] 978 International Telecommunications Union, "Common equipment 979 management function requirements", ITU-T Recommendation 980 G.7710, May 2008. 982 11.2. Informative References 984 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 985 "Introduction and Applicability Statements for Internet- 986 Standard Management Framework", RFC 3410, December 2002. 988 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 989 June 1999. 991 [RFC4181] Heard, C., "Guidelines for Authors and Reviewers of MIB 992 Documents", BCP 111, RFC 4181, September 2005. 994 [I-D.kunze-g-698-2-management-control-framework] 995 Kunze, R., "A framework for Management and Control of 996 optical interfaces supporting G.698.2", draft-kunze- 997 g-698-2-management-control-framework-00 (work in 998 progress), July 2011. 1000 [RFC4054] Strand, J. and A. Chiu, "Impairments and Other Constraints 1001 on Optical Layer Routing", RFC 4054, May 2005. 1003 Appendix A. Change Log 1005 This optional section should be removed before the internet draft is 1006 submitted to the IESG for publication as an RFC. 1008 Note to RFC Editor: please remove this appendix before publication as 1009 an RFC. 1011 Appendix B. Open Issues 1013 Note to RFC Editor: please remove this appendix before publication as 1014 an RFC. 1016 Authors' Addresses 1018 Gabriele Galimberti (editor) 1019 Cisco 1020 Via Santa Maria Molgora, 48 c 1021 20871 - Vimercate 1022 Italy 1024 Phone: +390392091462 1025 Email: ggalimbe@cisco.com 1027 Ruediger Kunze (editor) 1028 Deutsche Telekom 1029 Dddd, xx 1030 Berlin 1031 Germany 1033 Phone: +49xxxxxxxxxx 1034 Email: RKunze@telekom.de 1036 Kam Lam (editor) 1037 Alcatel-Lucent 1038 USA 1040 Phone: +1 732 331 3476 1041 Email: kam.lam@alcatel-lucent.com 1042 Dharini Hiremagalur (editor) 1043 Juniper 1044 1194 N Mathilda Avenue 1045 Sunnyvale - 94089 California 1046 USA 1048 Email: dharinih@juniper.net 1050 Gert Grammel (editor) 1051 Juniper 1052 Oskar-Schlemmer Str. 15 1053 80807 Muenchen 1054 Germany 1056 Phone: +49 1725186386 1057 Email: ggrammel@juniper.net 1059 Luyuan Fang (editor) 1060 Microsoft 1061 5600 148th Ave NE 1062 Redmond, WA 98502 1063 USA 1065 Email: lufang@microsoft.com 1067 Gary Ratterree (editor) 1068 Microsoft 1069 5600 148th Ave NE 1070 Redmond, WA 98502 1071 USA 1073 Email: gratt@microsoft.com