idnits 2.17.1 draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-13.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 document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (July 24, 2019) is 1737 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC6241' is mentioned on line 661, but not defined == Missing Reference: 'RFC8040' is mentioned on line 662, but not defined == Missing Reference: 'RFC4873' is mentioned on line 701, but not defined Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force R. Kunze, Ed. 3 Internet-Draft Deutsche Telekom 4 Intended status: Informational G. Grammel, Ed. 5 Expires: January 25, 2020 Juniper 6 D. Beller 7 Nokia 8 G. Galimberti, Ed. 9 Cisco 10 J. Meuric 11 Orange 12 July 24, 2019 14 A framework for Management and Control of DWDM optical interface 15 parameters 16 draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-13 18 Abstract 20 The control and management of DWDM interfaces are a precondition for 21 enhanced multilayer networking. They are needed to ensure an 22 efficient data transport, to meet the requirements requested by 23 today's IP-services and to provide a further automation of network 24 provisioning and operations. This document describes use cases, 25 requirements and solutions for the control and management of optical 26 interface parameters according to different types of single channel 27 DWDM interfaces. The focus is on automating the network provisioning 28 process irrespective on how it is triggered i.e. by Element Manager 29 System (EMS), Network Management System (NMS) or Generalized Multi 30 Protocol Label Switching (GMPLS). This document covers management 31 and control considerations in different scenarios of single channel 32 DWDM interfaces. The purpose is to identify the necessary 33 information and processes to be used by control or management systems 34 to properly and efficiently drive the network. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at https://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on January 25, 2020. 53 Copyright Notice 55 Copyright (c) 2019 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (https://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 71 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 72 2. Terminology and Definitions . . . . . . . . . . . . . . . . . 4 73 3. Solution Space . . . . . . . . . . . . . . . . . . . . . . . 5 74 3.1. Comparison of Approaches for Transverse Compatibility . . 6 75 3.1.1. Multivendor DWDM Line System with Transponders . . . 6 76 3.1.2. Integrated Single Channel DWDM Deployments on the 77 Client Site . . . . . . . . . . . . . . . . . . . . . 7 78 4. Solutions for Managing and Controlling Single Channel Optical 79 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 9 80 4.1. Separate Operation and Management Approaches . . . . . . 10 81 4.1.1. Direct Connection to the Management System . . . . . 10 82 4.1.2. Indirect Connection to the DWDM Management System 83 (First Optical Node) . . . . . . . . . . . . . . . . 11 84 4.2. Control Plane Considerations . . . . . . . . . . . . . . 13 85 4.2.1. Considerations Using GMPLS Signaling . . . . . . . . 14 86 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 15 87 6. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . 16 88 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18 89 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 90 8.1. Normative References . . . . . . . . . . . . . . . . . . 18 91 8.2. Informative References . . . . . . . . . . . . . . . . . 20 92 Appendix A. Use Cases . . . . . . . . . . . . . . . . . . . . . 21 93 A.1. Optical interface parameter collection . . . . . . . . . 21 94 A.2. DWDM client - ROADM interconection discovery . . . . . . 21 95 A.3. Service Setup . . . . . . . . . . . . . . . . . . . . . . 21 96 A.4. Link Monitoring Use Cases . . . . . . . . . . . . . . . . 22 97 A.4.1. Pure Access Link (AL) Monitoring Use Case . . . . . . 25 98 A.4.2. Power Control Loop Use Case . . . . . . . . . . . . . 27 99 A.5. Optical Circuit restoration . . . . . . . . . . . . . . . 29 100 A.6. Multilayer restoration . . . . . . . . . . . . . . . . . 29 101 Appendix B. Detailed info drafts . . . . . . . . . . . . . . . . 29 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 104 1. Introduction 106 The usage of external single channel Dense Wavelenght Division 107 Multiplexing (DWDM) interfaces (e.g. in routers) connected to a DWDM 108 Network (e.g. router connected to a network of Reconfigurable Optical 109 Add Drop Multiplexers (ROADM) and optical amplifiers) adds a further 110 networking option for operators but requires an harmonised control 111 and management plane interaction between the different network 112 domains. 114 Carriers deploy their networks today based on transport and packet 115 network infrastructures as domains to ensure high availability and a 116 high level of redundancy combining the Packet and Transport 117 restoration. Both network domains were operated and managed 118 separately. This is the status quo in many carrier networks today. 119 In the case of deployments where the optical transport interface 120 moves into the client device (e.g. router) an interaction between 121 those domains becomes necessary (e.g. Lambda reprovisioning due to 122 an optical restoration). 124 This framework specifies different levels of control and management 125 plane interaction to support the usage of single channel optical 126 interfaces in carrier networks in an efficient manner. The 127 interfaces between the two layers can be either gray or coloured. 129 Although Optical routing and wavelength assignment based on 130 Wavelenght Switched Optical Network (WSON) is out of scope, they can 131 benefit from the optical parameters that are exchanged between the 132 Client and the DWDM Network. Also, the wavelength ordering process 133 and determining the demand for a new wavelength path through the 134 network are out of scope. The GMPLS and PCE functions will use the 135 information collected from the Client and the DWDM network, the 136 definition on how PCE and GMPLS can use the information and cooperate 137 to implement RWA and circuit/service provisioning ar aout of scope of 138 this document. 140 Note that the Control and Management Planes are two separate entities 141 that may handle the same information in different ways. 143 1.1. Requirements Language 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 147 "OPTIONAL" in this document are to be interpreted as described in 148 BCP_14, RFC 2119 [RFC2119], RFC 8174 [RFC8174] when, and only when, 149 they appear in all capitals, as shown here. 151 While RFC 2119 [RFC2119] RFC 8174 [RFC8174] describe interpretations 152 of these key words in terms of protocol specifications and 153 implementations, they are used in this document to describe design 154 requirements for protocol extensions. 156 2. Terminology and Definitions 158 The current generation of Wavelenght Division Multiplexing (WDM) 159 networks are single vendor networks where the optical line system and 160 the transponders are tightly integrated. The DWDM interface 161 migration from integrated transponders to third party transponders or 162 colored interfaces change this scenario and introduces a standardized 163 interface at the level of OCh between the DWDM interface and the DWDM 164 network. 166 Black Link: The Black Link [ITU-T.G.698.2] allows supporting an 167 optical transmitter/receiver pair (of a single vendor or from 168 different vendors) to provide a single optical channel interface and 169 transport it over an optical network composed of amplifiers, filters, 170 add-drop multiplexers these being possibly from different vendors. 171 Therefore the standard defines the ingress and egress parameters for 172 the optical interfaces at the reference points Source side (Ss) and 173 Receive side (Rs). 175 Single Channel DWDM Interface: The single channel interfaces to DWDM 176 systems defined in [ITU-T.G.698.2], which currently include the 177 following features: channel frequency spacing: 50 GHz and wider 178 (defined in [ITU-T.G.694.1] ); bit rate of single channel: Up to 100 179 Gbit/s. Future revisions are expected to include application codes 180 for bit rates up to 400 Gbit/s. 182 Forward Error Correction (FEC): FEC is a way of improving the 183 performance of high-capacity optical transmission systems. Employing 184 FEC in optical transmission systems yields system designs that can 185 accept relatively large BER (much more than 10^-12) in the optical 186 transmission line (before decoding). 188 Administrative domain [ITU-T.G.805]: the extent of resources which 189 belong to a single player such as a network operator, a service 190 provider or an end-user. Administrative domains of different players 191 do not overlap amongst themselves. 193 Intra-domain interface (IaDI) [ITU-T.G.872]: A physical interface 194 within an administrative domain. 196 Inter-domain interface (IrDI) [ITU-T.G.872]: A physical interface 197 that represents the boundary between two administrative domains. 199 Management Plane [ITU-T.G.8081],: The management plane performs 200 management functions for the transport plane, the control plane and 201 the system as a whole. It also provides coordination between all the 202 planes. The following management functional areas are performed in 203 the management plane: performance management, fault management, 204 configuration management, accounting management and security 205 management. 207 Control Plane [ITU-T.G.8081]: Through signaling, the control plane 208 sets up and releases connections, may restore a connection in case of 209 a failure, and also performs other functions (e.g., neighbor 210 discovery, topology distribution) in support of those. 212 Transponder: A Transponder is a network element that performs O/E/O 213 (Optical /Electrical/Optical) conversion. In this document it is 214 referred only transponders with 3R (rather than 2R or 1R 215 regeneration) as defined in [ITU-T.G.872]. 217 Line System: A Line System is a portion of the network including 218 Reconfigurable Add Drop Multiplexers (ROADM) Line Amplifiers and the 219 the fibers connecting them. 221 Client DWDM interface: A Transceiver element that performs E/O 222 (Electrical/Optical) conversion. In this document it is referred as 223 the DWDM side of a transponder as defined in [ITU-T.G.872]. 225 3. Solution Space 227 The solution space of this document is focusing on aspects related to 228 the management and control of single-channel optical interface 229 parameters of physical point-to-point and ring DWDM applications on 230 single-mode optical fibres and allows the direct connection of a wide 231 variety of equipment using a DWDM link, for example 233 1. A digital cross-connect with multiple optical interfaces, 234 supplied by a different vendor from the line system 236 2. Devices as routing, switching or compute nodes, each from a 237 different vendor, providing optical line interfaces 239 3. A set of Data Center Equipment and servers 241 4. A combination of the above 243 3.1. Comparison of Approaches for Transverse Compatibility 245 This section describes two ways to achieve transverse compatibility. 246 Section 3.1.1 describes the classic model based on well defined 247 inter-domain interfaces. Section 3.1.2 defines a model ensuring 248 interoperability on the line side of the optical network. 250 3.1.1. Multivendor DWDM Line System with Transponders 252 As illustrated in Figure 1, for this approach interoperability is 253 achieved via the use of optical transponders providing OEO (allowing 254 conversion to appropriate parameters). The optical interfaces can 255 then be any short reach standardized optical interface that both 256 vendors support, such as those found in [ITU-T.G.957], [ITU-T.G.691], 257 [ITU-T.G.693], etc. 259 IrDI IaDI 260 | | 261 . . 262 | +----------------------------|----+ 263 . | + WDM Domain + . | 264 | | |\ /| | | 265 +------+ . | | \ |\ / | . | +------+ 266 | TX/ |-->--+---+--T/-|OM|----|/-------|OD|--+-\T-+---->--| RX/ | 267 | RX |--<--+---+--T/-| |----- /|-----| |--.-\T-+----<--| TX | 268 +------+ | | | / \| \ | | | +------+ 269 . | |/ \| . | 270 | | + + | | 271 . +----------------------------.----+ 272 | | 274 TX/RX = Single channel non-DWDM interfaces 275 T/ = Transponder 276 OM = Optical Mux 277 OD = Optical Demux 279 Figure 1: Inter and Intra-Domain Interface Identification 281 In the scenario of Figure 1 the administrative domain is defined by 282 the Interdomain Interface (IrDI). This interface terminates the DWDM 283 domain. The line side is characterized by the Intradomanin Interface 284 (IaDI). This interface specifies the internal parameter set of the 285 optical administrative domain. In the case of a client DWDM 286 interface deployment this IaDI moves into the client device and 287 extends the optical and administrative domain towards the client 288 node. [ITU-T.G.698.2] for example specifies a set of parameter set 289 for a certain set of applications, see Section 3.1.2. 291 This document elaborates only the IaDI (Intra Domain Interface) as 292 shown in Figure 1 as DWDM transversely compatible and multi-vendor 293 interface within one administrative domain controlled by the network 294 operator. 296 SNMP/Simple Management Interface (SMI), NETCONF/RESTCONF and Link 297 Management Protocol (LMP) TLV to support the direct exchange of 298 information between the client and the network management and control 299 plane will be specified in further documents. 301 The YANG based NETCONF and RESTCONF protocol are better suited for 302 creating and modifying configuration state and thus RECOMMENDED to be 303 used over SNMP MIB. The SNMP MIB creating and modifying 304 configuration state could be used for legacy network. 306 3.1.2. Integrated Single Channel DWDM Deployments on the Client Site 308 In case of a deployment as shown in Figure 2, through the use of DWDM 309 interfaces, multi-vendor interconnection can also be achieved. Among 310 the possible use cases, it may be used to remove the need for one 311 short reach transmitter and receiver pair per channel (eliminating 312 the transponders). 314 Figure 2 shows a set of reference points, for single-channel 315 connection (Ss and Rs) between transmitters (Tx) and receivers (Rx). 316 Here the DWDM network elements include an optical multiplexer (OM) 317 and an optical demultiplexer (OD) (which are used as a pair with the 318 peer element), one or more optical amplifiers and may also include 319 one or more ROADMs. 321 |==================== Black Link =======================| 323 +-------------------------------------------------+ 324 Ss | | DWDM Network Elements | | Rs 325 +---+ | | | \ / | | | +---+ 326 Tx L1---|->| \ +------+ +------+ / |--|-->Rx L1 327 +---+ | | | | | +------+ | | | | | +---+ 328 +---+ | | | | | | | | | | | | +---+ 329 Tx L2---|->| OM |-|>|------|->| ROADM|--|------|->| OD |--|-->Rx L2 330 +---+ | | | | | | | | | | | | +---+ 331 +---+ | | | | | +------+ | | | | | +---+ 332 Tx L3---|->| / | DWDM | | ^ | DWDM | \ |--|-->Rx L3 333 +---+ | | / | Link +----|--|----+ Link | \ | | +---+ 334 +-----------+ | | +----------+ 335 +--+ +--+ 336 |==== Black Link ====| | | 337 v | 338 +-----+ +-----+ 339 |RxLx | |TxLx | 340 +-----+ +-----+ 342 Ss = Reference point at the DWDM network element tributary output 343 Rs = Reference point at the DWDM network element tributary input 344 Lx = Lambda x 345 OM = Optical Mux 346 OD = Optical Demux 347 ROADM = Reconfigurable Optical Add Drop Mux 349 Linear DWDM network as per ITU-T G.698.2 351 Figure 2: Linear Black Link 353 The single administrative domain may consist of several vendor 354 domains. Even in that case a common network management and control 355 is required to ensure a consistent operation and provisioning of the 356 entire connection. 358 SNMP/SMI, NETCONF/RESTCONF and LMP TLV to support the direct exchange 359 of information between the client and the network management and 360 control plane will be specified in further documents. 362 4. Solutions for Managing and Controlling Single Channel Optical 363 Interface 365 Operation and management of WDM systems is traditionally seen as a 366 homogenous group of tasks that could be carried out best when a 367 single management system or a hierarchical management system is used. 368 Currently each WDM vendor provides an Element Management System (EMS) 369 that also provisions the wavelengths. In a multi-vendor line system, 370 such single-vendor EMS requirement is no more effective. New methods 371 of managing and controlling line systems need to be looked at. 373 Therefore from the operational point of view the following approaches 374 will be considered to manage and operate optical interfaces. 376 1. Separate operation and management of client device and the 377 transport network whereas the interface of the client belongs to 378 the administrative domain of the transport network and will be 379 managed by the transport group. This results in two different 380 approaches to send information to the management system 382 a. Direct connection from the client node to the transport 383 management system, ensuring a management of the DWDM interface of 384 the optical network (e.g. EMS, NMS) 386 b. Indirect connection to the management system of the optical 387 network using a protocol (e.g. LMP) between the client device 388 and the directly connected WDM system node to exchange management 389 information with the optical domain 391 2. Common operation and management of client device including the 392 single channel DWDM part and the Transport network 394 The first option keeps the status quo in large carrier networks as 395 mentioned above. In that case it must be ensured that the full FCAPS 396 Management (Fault, Configuration, Accounting, Performance and 397 Security) capabilities are supported. This means from the management 398 staff point of view nothing changes. The transceiver/receiver 399 optical interface will be part of the optical management domain and 400 will be managed from the transport management staff. 402 The second solution addresses the case where underlying WDM transport 403 network is mainly used to interconnect a homogeneous set of client 404 nodes (e.g. IP routers or digital crossconnects). Since the service 405 creation and restoration could be done by the higher layers (e.g. 407 IP), this may lead to an efficient network operation and a higher 408 level of integration. 410 4.1. Separate Operation and Management Approaches 412 4.1.1. Direct Connection to the Management System 414 As depicted in Figure 3 (case 1a) one possibility to manage the 415 optical interface within the client domain is a direct connection to 416 the management system of the optical domain. This ensures 417 manageability as usual. 419 +-----+ 420 | NMS | 421 |_____| 422 /_____/ 423 | 424 | 425 | 426 +---+---+ 427 +----->+ EMS | 428 / | | 429 / +-------+ 430 / | MI SNMP or NETCONF/RESTCONF 431 SNMP / or NETCONF | DCN Network 432 --------------------+------------------------------- 433 / +------+-----------------------+ 434 / | +| WDM Domain + | 435 / | |\ /| | 436 +---+--+ | | \ |\ / | | +------+ 437 | CL |-/C------+-----|OM|----|/-------|OD|----+-------/C-| CL | 438 | |-/C------+-----| |----- /|-----| |----+-------/C-| | 439 +------+ | | / \| \ | | +------+ 440 | |/ \| | 441 | + + | 442 +------------------------------+ 444 CL = Client Device 445 /C = Single Channel Optical Interface 446 OM = Optical Mux 447 OD = Optical Demux 448 EMS = Element Management System 449 MI = Management Interface 450 DCN = Data Control Network 452 Figure 3: Connecting Single Channel optical interfaces to the 453 Transport Management system 455 The exchange of management information between client device and the 456 management system assumes that some form of a direct management 457 communication link exists between the client device and the DWDM 458 management system (e.g. EMS). This may be an Ethernet Link or a DCN 459 connection (management communication channel MCC). 461 It must be ensured that the optical network interface can be managed 462 in a standardized way to enable interoperable solutions between 463 different optical interface vendors and vendors of the optical 464 network management application. [RFC3591] defines managed objects 465 for the optical interface type but needs further extension to cover 466 the optical parameters required by this framework document. 468 Is to be noted that the CL (client device) and the DWDM network are 469 belonging to the same operator so the DWDM EMS and the Client devices 470 are connected to the same DCN and the communication security 471 considerations are applicable to CL as per DWDM devices. 473 Note that a software update of the optical interface components of 474 the client nodes must not lead obligatory to an update of the 475 software of the EMS and vice versa. 477 4.1.2. Indirect Connection to the DWDM Management System (First Optical 478 Node) 480 An alternative as shown in Figure 4 should be used in cases where a 481 more integrated relationship between transport node (e.g. OM or OD 482 or ROADM) and client device is aspired. In that case a combination 483 of control plane features and manual management will be used. 485 +-----+ 486 | NMS | 487 |_____| 488 /_____/ 489 | 490 | 491 +---+---+ 492 | EMS | 493 | | 494 +-------+ 495 | MI SNMP or NETCONF/RESTCONF 496 | 497 LMP +------+-----------------------+ 498 +------------+---+ +| + | 499 | | | |\ /| | 500 +---+--+ | +-+ \ |\ / | | +------+ 501 | CL |-/C------+--- -|OM|----|/-------|OD|--- +-------/C-| CL | 502 | |-/C------+--- -| |----- /|-----| |----+-------/C-| | 503 +------+ | | / \| \ | | +------+ 504 | |/ \| | 505 | + + | 506 +------------------------------+ 508 CL = Client Device 509 /C = Single Channel optical Interface 510 OM = Optical Mux 511 OD = Optical Demux 512 EMS= Element Management System 513 MI= Management Interface 515 Figure 4: Direct connection between peer node and first optical 516 network node 518 For information exchange between the client node and the direct 519 connected node of the optical transport network LMP as specified in 520 RFC 4209 [RFC4209] should be used. This extension of LMP may be used 521 between a peer node and an adjacent optical network node as depicted 522 in Figure 4. 524 At the time of writing this document, LMP does not yet support the 525 transmission of configuration data (information). This functionality 526 is addressed by draft-ietf-ccamp-dwdm-if-lmp extending the RFC 4209 527 [RFC4209]. The use of LMP assumes that some form of a control 528 channel exists between the client node and the WDM equipment. This 529 may be a dedicated lambda or an Ethernet Link. 531 4.2. Control Plane Considerations 533 The concept of integrated single channel DWDM interfaces equally 534 applies to management and control plane mechanisms. GMPLS control 535 plane protocols have been extended for WSON, e.g. RFC 7689 [RFC7689] 536 ) for fixed grid signal and for flexi-grid RFC 7792 [RFC7792] ). One 537 important aspect of the Black Link [ITU-T.G.698.2] is the fact that 538 it is specific to the wavelength that is supported by the given link. 539 Therefore, the link can logically be considered as a fiber that is 540 transparent only for a single wavelength. In other words, the 541 wavelength becomes a characteristic of the link itself. 543 Nevertheless the procedure to light up the fiber may vary depending 544 on the implementation. Since the implementation is unknown a priori, 545 different sequences to light up a wavelength need to be considered: 547 1. Interface first, interface tuning: The transmitter is switched on 548 and the link is immediately transparent to its wavelength. This 549 requires the transmitter to carefully tune power and frequency 550 not overload the line system or to create transients. 552 2. Interface first, Optical Line System (OLS) tuning: The 553 transmitter is switched on first and can immediately go to the 554 max power allowed since the OLS performs the power tuning. This 555 leads to an intermediate state where the receiver does not 556 receive a valid signal while the transmitter is sending out one. 557 Alarm suppression mechanisms shall be employed to overcome that 558 condition. 560 3. OLS first, interface tuning: At first the OLS is tuned to be 561 transparent for a given wavelength, then transponders need to be 562 tuned up. Since the OLS in general requires the presence of a 563 wavelength to fine-tune its internal facilities there may be a 564 period where a valid signal is transmitted but the receiver is 565 unable to detect it. This equally need to be covered by alarm 566 suppression mechanisms. 568 4. OLS first, OLS tuning: The OLS is programmed to be transparent 569 for a given wavelength, then the interfaces need to be switched 570 on and further power tuning takes place. The sequencing of 571 enabling the link needs to be covered as well. 573 The preferred way to address these in a Control Plane enabled network 574 is neighbour discovery including exchange of link characteristics and 575 link property correlation. The general mechanisms are covered in RFC 576 4209 [RFC4209] and RFC 4204 [RFC4204] which provides the necessary 577 protocol framework to exchange those characteristics between client 578 and Black Link. LMP-WDM is not intended for exchanging routing or 579 signaling information nor to provision the lambda in the transceiver 580 but covers: 582 1. Control channel management 584 2. Link property correlation 586 3. Link verification 588 4. Fault management 590 Extensions to LMP covering the parameter sets (e.g. application 591 codes) are needed, see draft-ietf-ccamp-dwdm-if-lmp. Additionally, 592 when client and server side are managed by different operational 593 entities, the link state may be useful to help the management system 594 to do troubleshooting or alarm correlation. 596 4.2.1. Considerations Using GMPLS Signaling 598 The deployment of single channel optical interfaces is leading to 599 some functional changes related to the control plane models and has 600 therefore some impact on the existing interfaces especially in the 601 case of a model where the edge node requests resources from the core 602 node and the edge node do not participate in the routing protocol 603 instance that runs among the core nodes. RFC 4208 [RFC4208] defines 604 the GMPLS UNI that can be used between edge and core node. In case 605 of integrated interfaces deployment additional functionalities are 606 needed to setup a connection. 608 It is necessary to differentiate between topology/signalling 609 information and configuration parameters that are needed to setup a 610 wavelength path. Using RSVP-TE could be used for the signalling and 611 the reservation of the wavelength path. But there are additional 612 information needed before RSVP-TE can start the signalling process. 613 There are three possibilities to proceed: 615 a. Using RSVP-TE only for the signalling and LMP as described above 616 to exchange information on the configured optical interface 617 within the edge node 619 b. RSVP-TE (typically with loose ERO) to transport additional 620 information 622 c. Leaking IGP information instead of exchanging this information 623 needed from the optical network to the edge node (UNI will be 624 transformed to a border-peer model, see RFC 5146 [RFC5146] ) 626 Furthermore following issues should be addressed: 628 a) The transceivers of peering edge nodes must be compatible. For 629 example, it may be required to know about FEC, modulation scheme, The 630 modulation format, the baudrate and many other parameters described 631 in the drafts reported in the Annex. Depending on where the 632 information is available, compatibility check may either happen 633 before signaling, when the signaling reaches the optical network 634 (e.g. at path computation time), or in the tail end node. An 635 extended version of LMP is needed to exchange this information in 636 case a. above, and to RSVP-TE as well in b. It would be helpful to 637 define some common profiles that will be supported (e.g. the 638 "application identifier") to summarize interface capabilities: if 639 both profiles match, signaling can succeed and provisioning be 640 achieved. 642 b) Due to the bidirectional wavelength path that must be setup, the 643 upstream edge node must include a wavelength value into the RSVP-TE 644 Path message. But in the case of a UNI model the client device may 645 not have full information about which wavelength must/should be 646 selected, whereas this information must be exchanged between the edge 647 and the core node. The special value defined in 648 [Network-Assigned-Upstream-Label] allows the optical network to 649 assign the actual wavelength to be used by the upstream transponder, 650 which is a simple and efficient solution to this issue. 652 5. Requirements 654 As network architectures become more complex, management and 655 operations, including the the provisioning process, need progress 656 towards automation. Simplifying and automating the entire management 657 as well as the network provisioning process while enabling higher 658 link utilization and faster restoration times are the main targets of 659 this section. 661 Supporting network management protocols such as NETCONF [RFC6241] or 662 RESTCONF [RFC8040] is the base for the communication among EMS/NMS, 663 centralized controller and network elements. This implies to speficy 664 the corresponding IETF YANG modules to fully and consistently manage 665 the feature discussed on this document. 667 Data plane interoperability as defined for example in [ITU-T.G.698.2] 668 is a precondition to take full benefit from standardized interfaces 669 between network and control/management plane. 671 The following requirements are focusing on the usage of DWDM 672 interfaces using IETF technologies. Obvisouly, a common set of 673 solutions must be consistently supported by both the devices hosting 674 DWDM interfaces and the WDM network (i.e., the WDM line). The 675 solutions addressing the following requirements will be discussed in 676 further documents. 678 1 A YANG data model MUST define the optical parameters to be 679 exchanged (e.g., power setting) between the network elements and 680 the management plane so as to configure single channel interfaces 681 through NETCONF/RESTCONF. 683 2 LMP MUST allow to convey the relevant optical parameters between 684 two nodes to correlate neighbor characteristics and identify 685 common capabilities or compatible ranges between the WDM line and 686 single channel interfaces. 688 3 RSVP-TE MUST support the relevant parameters to be exchanged 689 between the device hosting the DWDM interface and the optical node 690 (e.g. the label value), 691 without preventing the network to remain in charge of the optical 692 path computation. 694 4 Power monitoring functions at both ends of the DWDM connection 695 MAY be used to further automate the setup and shutdown process of 696 the optical interfaces. LMP SHOULD suppport a way to carry 697 associated measurement from the client devices to the edges of the 698 WDM network. 700 5 In fault cases, the network SHOULD be able to recover wavelengths. 701 RSVP-TE extensions MUST remain compatible with [RFC4873] features. 702 The Yang modules should mimic a similar level of capability. 704 6. Gap Analysis 706 To enable a centralized control function, several gaps in existing 707 RFCs have been identified: 709 1 RFC 8343 defines a generic YANG model for interface management. 710 However, to control DWDM interfaces, an augmentation needs to be 711 defined which allows to configure DWDM specifics such as wavelength 712 or FEC-type. 714 2 RFC 7224 defines iana-if-type YANG modules and needs extension to 715 include DWDM interfaces. 717 3 RFC 4204 defines the Link Management Protocol (LMP) to correlate 718 link properties between two adjacent nodes. Extensions are required 719 to cover the use cases described such as the correlation between a 720 Transponder and a ROADM node. 722 4 RFC 8454 defines an information model for Abstraction and 723 Control of TE Networks (ACTN). However it does not support 724 impairment aware path selection or computation. 726 5 RFC 7823 describes Performance-Based Path Selection for Explicitly 727 Routed Label Switched Paths (LSPs) Using TE Metric Extensions, 728 but does not define Metric extensions suitable for Impairment 729 aware routing in optical transport Networks 731 6 RFC 7471 in turn defines OSPF Traffic Engineering (TE) Metric 732 Extensions covering several use cases but lacks Imairment 733 awareness. 735 7 RFC 6163 provides a Framework for GMPLS and Path Computation 736 Element (PCE) Control of Wavelength Switched Optical Networks 737 (WSONs). While it describes methods for communicating RWA relevant 738 information, it does not identify such information. 740 8 Yang Models describing the optical parameter to be used to control 741 the network ad allow an external controller (like ACTN) to are 742 missing although are defined by ITU and reported in the 744 As this framework is focusing on the single operator use case, the 745 security concerns can be relaxed to a subset compared to a setup 746 where information is exchanged between external parties and over 747 external interfaces. 749 Concerning the access control to Management interfaces, security 750 issues can be generally addressed by authentication techniques 751 providing origin verification, integrity and confidentiality. 752 Additionally, access to Management interfaces can be physically or 753 logically isolated, by configuring them to be only accessible out-of- 754 band, through a system that is physically or logically separated from 755 the rest of the network infrastructure. In case where management 756 interfaces are accessible in-band at the client device or within the 757 optical transport network domain, filtering or firewalling techniques 758 can be used to restrict unauthorized in-band traffic. Authentication 759 techniques may be additionally used in all cases. 761 7. Contributors 763 Arnold Mattheus 764 Deutsche Telekom 765 Darmstadt 766 Germany 767 email arnold.Mattheus@telekom.de 769 Manuel Paul 770 Deutsche Telekom 771 Berlin 772 Germany 773 email Manuel.Paul@telekom.de 775 Josef Roese 776 Deutsche Telekom 777 Darmstadt 778 Germany 779 email j.roese@telekom.de 781 Frank Luennemann 782 Deutsche Telekom 783 Muenster 784 Germany 785 email Frank.Luennemann@telekom.de 787 Dharini Hiremagalur 788 Juniper 789 1133 Innovation Way 790 Sunnyvale - 94089 California 791 USA 792 dharinih@juniper.net 794 8. References 796 8.1. Normative References 798 [ITU-T.G.694.1] 799 International Telecommunications Union, "Spectral grids 800 for WDM applications: DWDM frequency grid", 801 ITU-T Recommendation G.694.1, Febriary 2012. 803 [ITU-T.G.698.2] 804 International Telecommunications Union, "Amplified 805 multichannel dense wavelength division multiplexing 806 applications with single channel optical interfaces", 807 ITU-T Recommendation G.698.2, November 2009. 809 [ITU-T.G.805] 810 International Telecommunications Union, "Spectral grids 811 for WDM applications: DWDM frequency grid", 812 ITU-T Recommendation G.805, March 2000. 814 [ITU-T.G.872] 815 International Telecommunications Union, "Architecture of 816 optical transport networks", ITU-T Recommendation G.872, 817 November 2001. 819 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 820 Requirement Levels", BCP 14, RFC 2119, 821 DOI 10.17487/RFC2119, March 1997, 822 . 824 [RFC3591] Lam, H-K., Stewart, M., and A. Huynh, "Definitions of 825 Managed Objects for the Optical Interface Type", RFC 3591, 826 DOI 10.17487/RFC3591, September 2003, 827 . 829 [RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC 4204, 830 DOI 10.17487/RFC4204, October 2005, 831 . 833 [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, 834 "Generalized Multiprotocol Label Switching (GMPLS) User- 835 Network Interface (UNI): Resource ReserVation Protocol- 836 Traffic Engineering (RSVP-TE) Support for the Overlay 837 Model", RFC 4208, DOI 10.17487/RFC4208, October 2005, 838 . 840 [RFC4209] Fredette, A., Ed. and J. Lang, Ed., "Link Management 841 Protocol (LMP) for Dense Wavelength Division Multiplexing 842 (DWDM) Optical Line Systems", RFC 4209, 843 DOI 10.17487/RFC4209, October 2005, 844 . 846 [RFC7689] Bernstein, G., Ed., Xu, S., Lee, Y., Ed., Martinelli, G., 847 and H. Harai, "Signaling Extensions for Wavelength 848 Switched Optical Networks", RFC 7689, 849 DOI 10.17487/RFC7689, November 2015, 850 . 852 [RFC7792] Zhang, F., Zhang, X., Farrel, A., Gonzalez de Dios, O., 853 and D. Ceccarelli, "RSVP-TE Signaling Extensions in 854 Support of Flexi-Grid Dense Wavelength Division 855 Multiplexing (DWDM) Networks", RFC 7792, 856 DOI 10.17487/RFC7792, March 2016, 857 . 859 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 860 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 861 May 2017, . 863 8.2. Informative References 865 [ITU-T.G.691] 866 ITU-T, "Optical interfaces for single channel STM-64 and 867 other SDH systems with optical amplifiers", 868 ITU-T Recommendation ITU-T G.691, 2008. 870 [ITU-T.G.693] 871 ITU-T, "Optical interfaces for intra-office systems", 872 ITU-T Recommendation ITU-T G.693, 2009. 874 [ITU-T.G.8081] 875 ITU-T, "Terms and definitions for Automatically Switched 876 Optical Networks (ASON)", ITU-T Recommendation G.8081", 877 ITU-T Recommendation ITU-T G.8081, September 2010. 879 [ITU-T.G.957] 880 ITU-T, "Optical interfaces for equipments and systems 881 relating to the synchronous digital hierarchy", 882 ITU-T Recommendation ITU-T G.957, 2006. 884 [Network-Assigned-Upstream-Label] 885 Internet Engineering Task Force, "Generalized Multi- 886 Protocol Label Switching (GMPLS) Resource reSerVation 887 Protocol with Traffic Engineering (RSVP- TE) mechanism 888 that enables the network to assign an upstream label for a 889 bidirectional LSP", draft-ietf-teas-network-assigned- 890 upstream-label draft-ietf-teas-network-assigned-upstream- 891 label, June 2017. 893 [RFC5146] Kumaki, K., Ed., "Interworking Requirements to Support 894 Operation of MPLS-TE over GMPLS Networks", RFC 5146, 895 DOI 10.17487/RFC5146, March 2008, 896 . 898 Appendix A. Use Cases 900 A comparison with the traditional operation scenarios provides an 901 insight of similarities and distinctions in operation and management 902 of DWDM interfaces. The following use cases provide an overview 903 about operation and maintenance processes. 905 A.1. Optical interface parameter collection 907 It is necessary to identify the Optical interface characteristics and 908 setting in order to properly calculate the ent to end path and match 909 the Head End interface against the Tail End interface compatibility. 910 The optical parameters may have multiple possible values that the 911 Controller (SDN or GMPLS) can use and select for the best network 912 optimisation. 914 A.2. DWDM client - ROADM interconection discovery 916 Being the the DWDM port and ROADM port belonging to different domains 917 and Network Elements, the interconnection between them is not 918 embedded in the Optical Nodes and can not be shared to the EMS and 919 the Controller. The Controller needs then to retrieve the 920 connectivity using data coming from the two domains correlating them 921 to discover the relationship. The methods to discover the 922 interconnection can be LMP, LLDP, installation provisioning or any 923 other mechanism checking using the light transmitted by the DWDM 924 transmitter and detecter by the ROAMD port photodiode. This use case 925 is fundamental to build the interconnections between the DWDM and 926 Client layer (e.g. Routers) and calculate the multilayer network 927 topology. 929 A.3. Service Setup 931 It is necessary to differentiate between different operational issues 932 for setting up a light path (a DWDM connection is specific in having 933 defined maximum impairments) within an operational network. 935 The first step is to determine if transceivers located at different 936 end-points are interoperable, i.e. support a common set of 937 operational parameters. In this step it is required to determine 938 transceiver capabilities in a way to be able to correlate them for 939 interoperability purposes. Such parameters include modulation 940 scheme, modulation parameters, FEC to name a few. If both 941 transceivers are controlled by the same NMS or CP, such data is 942 readily available. However in cases like Figure 4, a protocol needs 943 to be used to inform the controlling instance (NMS or CP) about 944 transceiver parameters. It is suggested to extend LMP for that 945 purpose. 947 The second step is to determine the feasibility of a lightpath 948 between two transceivers without applying an optical signal. 949 Understanding the limitations of the transceiver pair, a path through 950 the optical network has to be found, whereby each path has an 951 individual set of impairments deteriorating a wavelength traveling 952 along that path. Since a single transceiver can support multiple 953 parameter sets, the selection of a path may limit the permissible 954 parameter sets determined in previous steps. 956 The third step is then to setup the connection itself and to 957 determine the Wavelength. This is done using the NMS of the optical 958 transport network or by means of a control plane interaction such as 959 signaling and includes the path information as well as the parameter 960 set information necessary to enable communication. 962 In a fourth step, optical monitoring is activated in the WDM network 963 in order to monitor the status of the connection. The monitor 964 functions of the optical interfaces at the terminals are also 965 activated in order to monitor the end to end connection. 967 Furthermore it should be possible to automate this step. After 968 connecting the client device to the neighbor control plane-enabled 969 transport node, a control adjacency may be automatically established, 970 e.g. using LMP. 972 A.4. Link Monitoring Use Cases 974 The use cases described below are assuming that power monitoring 975 functions are available in the ingress and egress network element of 976 the DWDM network, respectively. By performing link property 977 correlation it would be beneficial to include the current transmit 978 power value at reference point Ss and the current received power 979 value at reference point Rs. For example if the Client transmitter 980 power has a value of 0dBm and the ROADM interface measured power is 981 -6dBm the fiber patch cord connecting the two nodes may be pinched or 982 the connectors are dirty. As discussed before, the actual path or 983 selection of a specific wavelength within the allowed set is outside 984 the scope of LMP. The computing entities (e.g. the first optical 985 node originating the circuit) can rely on GMPLS IGP (OSPF) to 986 retrieve all the information related to the network, calculate the 987 path to reach the endpoint and signal the path implementation through 988 the network via RSVP-TE. 990 [ITU-T.G.698.2] defines a single channel optical interface for DWDM 991 systems that allows interconnecting network-external optical 992 transponders across a DWDM network. The optical transponders are 993 external to the DWDM network. This so-called 'Black Link' approach 994 illustrated in Fig. 5-1 of [ITU-T.G.698.2] and a copy of this figure 995 is provided below in Figure 5. The single channel fiber link between 996 the Ss/Rs reference points and the ingress/egress port of the network 997 element on the domain boundary of the DWDM network (DWDM border NE) 998 is called access link. Based on the definition in [ITU-T.G.698.2] it 999 is part of the DWDM network. The access link is typically realized 1000 as a passive fiber link that has a specific optical attenuation 1001 (insertion loss). As the access link is an integral part of the DWDM 1002 network, it is desirable to monitor its attenuation. Therefore, it 1003 is useful to detect an increase of the access link attenuation, for 1004 example, when the access link fiber has been disconnected and 1005 reconnected (maintenance) and a bad patch panel connection 1006 (connector) resulted in a significantly higher access link 1007 attenuation (loss of signal in the extreme case of an open connector 1008 or a fiber cut). In the following section, two use cases are 1009 presented and discussed: 1011 1) pure access link monitoring 1012 2) access link monitoring with a power control loop 1014 These use cases require a power monitor as described in G.697 (see 1015 section 6.1.2), that is capable to measure the optical power of the 1016 incoming or outgoing single channel signal. The use case where a 1017 power control loop is in place could even be used to compensate an 1018 increased attenuation if the optical transmitter can still be 1019 operated within its output power range defined by its application 1020 code. 1022 Use case 1: Access Link monitoring 1024 +--------------------------+ 1025 | P(in) = P(Tx) - a(Tx) | 1026 | ___ | 1027 +----------+ | \ / Power Monitor | 1028 | | P(Tx) | V P(in) | 1029 | +----+ | Ss //\\ | | |\ | 1030 | | TX |----|-----\\//------------------->| \ | 1031 | +----+ | Access Link (AL-T) | . | | | 1032 | | attenuation a(Tx) | . | |==============> 1033 | | | . | | | 1034 | External | | --->| / | 1035 | Optical | | |/ | 1036 |Transpond.| | P(out) | 1037 | | | ___ | 1038 | | | \ / Power Monitor | 1039 | | P(Rx) | V P(out) | 1040 | +----+ | Rs //\\ | | |\ | 1041 | | RX |<---|-----\\//--------------------| \ | 1042 | +----+ | Access Link (AL-R) | . | | | 1043 | | Attenuation a(Rx) | . | |<============== 1044 +----------+ | . | | | 1045 | <---| / | 1046 P(Rx) = P(out) - a(Rx) | |/ | 1047 | | 1048 | ROADM | 1049 +--------------------------+ 1051 - For AL-T monitoring: P(Tx) and a(Tx) must be known 1052 - For AL-R monitoring: P(RX) and a(Rx) must be known 1054 An alarm shall be raised if P(in) or P(Rx) drops below a 1055 configured threshold (t [dB]): 1056 - P(in) < P(Tx) - a(Tx) - t (Tx direction) 1057 - P(Rx) < P(out) - a(Rx) - t (Rx direction) 1058 - a(Tx) =| a(Rx) 1060 Alarms and events can be shared between Client and Network 1061 via LMP. 1063 Figure 5: Access Link Power Monitoring 1065 A.4.1. Pure Access Link (AL) Monitoring Use Case 1067 Figure 6 illustrates the access link monitoring use case and the 1068 different physical properties involved that are defined below: 1070 - Ss, Rs: Single Channel reference points 1071 - P(Tx): current optical output power of transmitter Tx 1072 - a(Tx): access link attenuation in Tx direction (external 1073 transponder point of view) 1074 - P(in): measured current optical input power at the input port 1075 of border DWDM NE 1076 - t: user defined threshold (tolerance) 1077 - P(out): measured current optical output power at the output port 1078 of border DWDM NE 1079 - a(Rx): access link attenuation in Rx direction (external 1080 transponder point of view) 1081 - P(Rx): current optical input power of receiver Rx 1083 Description: 1084 - The access link attenuation in both directions (a(Tx), a(Rx)) 1085 is known or can be determined as part of the commissioning 1086 process. Typically, both values are very similar. 1087 - A threshold value t has been configured by the operator. This 1088 should also be done during commissioning. 1089 - A control plane protocol is in place that allows 1090 to periodically send the optical power values P(Tx) and P(Rx) 1091 to the control plane protocol instance on the DWDM border NE. 1092 This is illustrated in Figure 3. 1093 - The DWDM border NE is capable to periodically measure the optical 1094 power P(in) and P(out) as defined in G.697 by power monitoring 1095 points depicted as triangles in the figures below. 1097 Access Link monitoring process: 1098 - Tx direction: the measured optical input power P(in) is compared 1099 with the expected optical input power P(Tx) - a(Tx). If the 1100 measured optical input power P(in) drops below the value 1101 (P(Tx) - a(Tx) - t) a low power alarm shall be raised indicating 1102 that the access link attenuation has exceeded a(Tx) + t. 1103 - Rx direction: the measured optical input power P(Rx) is 1104 compared with the expected optical input power P(out) - a(Rx). 1105 If the measured optical input power P(Rx) drops below the value 1106 (P(out) - a(Rx) - t) a low power alarm shall be raised indicating 1107 that the access link attenuation has exceeded a(Rx) + t. 1108 - to avoid toggling errors, the low power alarm threshold shall be 1109 lower than the alarm clear threshold. 1111 Use case 2: Access Link monitoring through LMP 1113 +----------+ +--------------------------+ 1114 | +------+ | P(Tx), P(Rx) | +-------+ | 1115 | | | | =================> | | | | 1116 | | LMP | | P(in), P(out) | | LMP | | 1117 | | Agent| | <================= | | Agent | | 1118 | +------+ | | +-------+ | 1119 | | | | 1120 | | | P(in) - P(Tx) - a(Tx) | 1121 | | | ___ | 1122 | | | \ / Power Monitor | 1123 | | P(Tx) | V | 1124 | +----+ | Ss //\\ | | |\ | 1125 | | TX |----|-----\\//------------------->| \ | 1126 | +----+ | Access Link (AL-T) | . | | | 1127 | | attenuation a(Tx) | . | |==============> 1128 | | | . | | | 1129 | External | | --->| / | 1130 | Optical | | |/ | 1131 |Transpond.| | P(out) | 1132 | | | ___ | 1133 | | | \ / Power Monitor | 1134 | | P(Rx) | V | 1135 | +----+ | Rs //\\ | | |\ | 1136 | | RX |<---|-----\\//--------------------| \ | 1137 | +----+ | Access Link (AL-R) | . | | | 1138 | | Attenuation a(Rx) | . | |<============== 1139 +----------+ | . | | | 1140 | <---| / | 1141 P(Rx) = P(out) - a(Rx) | |/ | 1142 | | 1143 | ROADM | 1144 +--------------------------+ 1146 - For AL-T monitoring: P(Tx) and a(Tx) must be known 1147 - For AL-R monitoring: P(RX) and a(Rx) must be known 1148 An alarm shall be raised if P(in) or P(Rx) drops below a 1149 configured threshold (t [dB]): 1150 - P(in) < P(Tx) - a(Tx) - t (Tx direction) 1151 - P(Rx) < P(out) - a(Rx) - t (Rx direction) 1152 - a(Tx) = a(Rx) 1154 Alarms and events can be shared between Client and Network 1155 via LMP according to [RFC4204] and [RFC4209] 1156 Figure 6: Extended LMP Model 1158 A.4.2. Power Control Loop Use Case 1160 This use case is based on the access link monitoring as 1161 described above. In addition, the border NE is running a power 1162 control application that is capable to control the optical output 1163 power of the single channel tributary signal at the output port 1164 of the border DWDM NE (towards the external receiver Rx) and the 1165 optical output power of the single channel tributary signal at 1166 the external transmitter Tx within their known operating range. 1167 The time scale of this control loop is typically relatively slow 1168 (e.g. some 10s or minutes) because the access link attenuation 1169 is not expected to vary much over time (the attenuation only 1170 changes when re-cabling occurs). 1171 From a data plane perspective, this use case does not require 1172 additional data plane extensions. It does only require a protocol 1173 extension in the control plane (e.g. this LMP draft) that allows 1174 the power control application residing in the DWDM border NE to 1175 modify the optical output power of the DWDM domain-external 1176 transmitter Tx within the range of the currently used application 1177 code. Figure 7 below illustrates this use case utilizing 1178 LMP with the extensions identified in this document. 1180 Use case 3: Power Control Loop 1182 +----------+ +--------------------------+ 1183 | +------+ |P(Tx),P(Rx),Set(P(out))| +-------+ +--------+ | 1184 | | | | ====================> | | | | Power | | 1185 | | LMP | | P(in),P(out),Set(PTx) | | LMP | |Control | | 1186 | | | | <==================== | | | | Loop | | 1187 | +------+ | | +-------+ +--------+ | 1188 | | | | | 1189 | +------+ | | P(in) = P(Tx) - a(Tx) | 1190 | |C.Loop| | | ___ | 1191 | +------+ | | \ / Power Monitor | 1192 | | | P(Tx) | V | 1193 | +------+ | Ss //\\ | | |\ | 1194 | | TX |>----|-----\\//---------------------->| \ | 1195 | +------+ | Access Link (AL-T) | . | | | 1196 | VOA(Tx) | attenuation a(Tx) | . | |==============> 1197 | | | . | | | 1198 | External | | --->| / | 1199 | Optical | | |/ | 1200 |Transpond.| | P(out) | 1201 | | | ___ | 1202 | | | \ / Power Monitor | 1203 | | P(Rx) | V | 1204 | +----+ | Rs //\\ | | VOA(out) |\ | 1205 | | RX |<---|-----\\//---------------------<|-------| \ | 1206 | +----+ | Access Link (AL-R) | . | | | 1207 | | attenuation a(Rx) | . | |<======= 1208 +----------+ | VOA(out) | | | 1209 | <--<|-------| / | 1210 P(Rx) = P(out) - a(Rx) | |/ | 1211 | | 1212 | ROADM | 1213 +--------------------------+ 1215 Figure 7: Power control loop 1217 - The power control loop in transponders and ROADMs controls 1218 the Variable Optical Attenuators (VOA) to adjust the proper 1219 power in base of the ROADM and Receiver characteristics and 1220 the Access Link attenuation 1222 A.5. Optical Circuit restoration 1224 Upon an network failure (e.g. fiber cut) the Controller or GMPLS can 1225 initiate an Optical Path restoration process. Other than reroute the 1226 optical path the controller may need to retune the wavelength and 1227 modify the DWDM Transceiver working parameters (e.g. FEC, Modulation 1228 Format, etc.). This operation is done in realtime and can benefit of 1229 Netconf/Yang interface or RSVP signallin on the UNI interface. 1231 A.6. Multilayer restoration 1233 A network failure can be due to an DWDM port failure. The Controller 1234 is the only actor able to fix issue setting a new circuit terminated 1235 on a good Client port (GMPLS is not able to make an new path choosing 1236 a different end-point). Other than reroute the optical path the 1237 controller may need to provision the wavelength and modify the DWDM 1238 Transceiver working parameters (e.g. FEC, Modulation Format, etc.). 1239 This operation is done in realtime and must be supported by Netconf/ 1240 Yang interface. 1242 Appendix B. Detailed info drafts 1244 In this section are reported some examples and references on the MIB, 1245 Yang and LMP usage. The MIB and TLV defining the parameters 1246 described above are reported in the drafts below and are intended as 1247 informative data: 1249 Extension to the Link Management Protocol (LMP/DWDM -rfc4209) for 1250 Dense Wavelength Division Multiplexing (DWDM) Optical Line Systems 1251 to manage the application code of optical interface parameters in 1252 DWDM application 1254 draft-ggalimbe-ccamp-flex-if-lmp 1255 Extension to the Link Management Protocol (LMP/DWDM -rfc4209) for 1256 Dense Wavelength Division Multiplexing (DWDM) Optical Line Systems 1257 to manage the application code of optical interface parameters in 1258 DWDM application 1260 draft-ietf-ccamp-dwdm-if-param-yang 1261 A YANG model to manage the optical interface parameters for an 1262 external transponder in a WDM network 1264 draft-ietf-ccamp-flexigrid-yang 1265 YANG data model for Flexi-Grid Optical Networks 1267 draft-ietf-ccamp-wson-iv-info 1268 Information Model for Wavelength Switched Optical Networks (WSONs) 1269 with Impairments Validation 1271 draft-ietf-ccamp-wson-iv-encode 1272 Information Encoding for WSON with Impairments Validation 1274 draft-galimbe-ccamp-iv-yang 1275 A YANG model to manage the optical parameters for in a WDM network 1277 NOTE: the above information is defined at the time of publication of 1278 this document and thus subject to change. 1280 Authors' Addresses 1282 Ruediger Kunze (editor) 1283 Deutsche Telekom 1284 Winterfeldtstr. 21-27 1285 10781 Berlin 1286 Germany 1288 Phone: +491702275321 1289 Email: RKunze@telekom.de 1290 Gert Grammel (editor) 1291 Juniper 1292 Oskar-Schlemmer Str. 15 1293 80807 Muenchen 1294 Germany 1296 Phone: +49 1725186386 1297 Email: ggrammel@juniper.net 1299 Dieter Beller 1300 Nokia 1301 Lorenzstrasse, 10 1302 70435 Stuttgart 1303 Germany 1305 Phone: +4971182143125 1306 Email: Dieter.Beller@nokia.com 1308 Gabriele Galimberti (editor) 1309 Cisco 1310 Via S. Maria Molgora, 48c 1311 20871 - Vimercate 1312 Italy 1314 Phone: +390392091462 1315 Email: ggalimbe@cisco.com 1317 Julien Meuric 1318 Orange 1319 2, Avenue Pierre Marzin 1320 22307 Lannion Cedex 1321 France 1323 Phone: +33 1324 Email: julien.meuric@orange.com