idnits 2.17.1 draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-09.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 15, 2017) is 2321 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 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: June 18, 2018 Juniper 6 D. Beller 7 Nokia 8 G. Galimberti, Ed. 9 Cisco 10 J. Meuric 11 Orange 12 December 15, 2017 14 A framework for Management and Control of DWDM optical interface 15 parameters 16 draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-09 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 EMS, NMS or 29 GMPLS. This document covers management and control considerations in 30 different scenarios of single channel DWDM interfaces. The purpose 31 is to identify the necessary information and processes to be used by 32 control or management systems to properly and efficiently drive the 33 network. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at https://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on June 18, 2018. 51 Copyright Notice 53 Copyright (c) 2017 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (https://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 69 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 70 2. Terminology and Definitions . . . . . . . . . . . . . . . . . 4 71 3. Solution Space . . . . . . . . . . . . . . . . . . . . . . . 5 72 3.1. Comparison of Approaches for Transverse Compatibility . . 5 73 3.1.1. Multivendor DWDM Line System with Transponders . . . 5 74 3.1.2. Integrated Single Channel DWDM Deployments on the 75 Client Site . . . . . . . . . . . . . . . . . . . . . 7 76 4. Solutions for Managing and Controlling Single Channel Optical 77 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 9 78 4.1. Separate Operation and Management Approaches . . . . . . 10 79 4.1.1. Direct Connection to the Management System . . . . . 10 80 4.1.2. Indirect Connection to the DWDM Management System 81 (First Optical Node) . . . . . . . . . . . . . . . . 11 82 4.2. Control Plane Considerations . . . . . . . . . . . . . . 13 83 4.2.1. Considerations Using GMPLS Signaling . . . . . . . . 14 84 5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 15 85 5.1. Service Setup . . . . . . . . . . . . . . . . . . . . . . 15 86 5.2. Link Monitoring Use Cases . . . . . . . . . . . . . . . . 16 87 5.2.1. Pure Access Link (AL) Monitoring Use Case . . . . . . 19 88 5.2.2. Power Control Loop Use Case . . . . . . . . . . . . . 21 89 6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 23 90 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 91 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 92 9. Security Considerations . . . . . . . . . . . . . . . . . . . 25 93 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25 94 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 95 11.1. Normative References . . . . . . . . . . . . . . . . . . 26 96 11.2. Informative References . . . . . . . . . . . . . . . . . 28 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 100 1. Introduction 102 The usage of external single channel DWDM interfaces (e.g. in 103 routers) connected to a DWDM Network (e.g. router connected to a 104 network of ROADMs and optical amplifiers) adds a further networking 105 option for operators but requires an harmonised control and 106 management plane interaction between the different network domains. 108 Carriers deploy their networks today based on transport and packet 109 network infrastructures as domains to ensure high availability and a 110 high level of redundancy combining the Packet and Transport 111 restoration. Both network domains were operated and managed 112 separately. This is the status quo in many carrier networks today. 113 In the case of deployments where the optical transport interface 114 moves into the client device (e.g. router) an interaction between 115 those domains becomes necessary (e.g. Lambda reprovisioning due to 116 an optical restoration). 118 This framework specifies different levels of control and management 119 plane interaction to support the usage of single channel optical 120 interfaces in carrier networks in an efficient manner. The 121 interfaces between the two layers can be wither gray or coloured. 123 Although Optical routing and wavelength assignment based on WSON is 124 out of scope, they can benefit from the optical parameters that are 125 exchanged between the Client and the DWDM Network. Also, the 126 wavelength ordering process and determining the demand for a new 127 wavelength path through the network are out of scope. 129 Note that the Control and Management Planes are two separate entities 130 that may handle the same information in different ways. 132 1.1. Requirements Language 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 136 document are to be interpreted as described in RFC 2119 [RFC2119]. 138 While RFC 2119 [RFC2119] describes interpretations of these key words 139 in terms of protocol specifications and implementations, they are 140 used in this document to describe design requirements for protocol 141 extensions. 143 2. Terminology and Definitions 145 The current generation of WDM netwoks are single vendor networks 146 where the optical line system and the transponders are tightly 147 integrated. The DWDM interface migration from integrated 148 transponders to third party transponders or colored interfaces change 149 this scenario and introduces a standardized interface at the level of 150 OCh between the DWDM interface and the DWDM network. 152 Black Link: The Black Link [ITU-T.G.698.2] allows supporting an 153 optical transmitter/receiver pair (of a single vendor or from 154 different vendors) to provide a single optical channel interface and 155 transport it over an optical network composed of amplifiers, filters, 156 add-drop multiplexers these being possibly from different vendors. 157 Therefore the standard defines the ingress and egress parameters for 158 the optical interfaces at the reference points Ss and Rs. 160 Single Channel DWDM Interface: The single channel interfaces to DWDM 161 systems defined in [ITU-T.G.698.2], which currently include the 162 following features: channel frequency spacing: 50 GHz and wider 163 (defined in [ITU-T.G.694.1]; bit rate of single channel: Up to 10 164 Gbit/s. Future revisions are expected to include application codes 165 for bit rates up to 40 Gb/s. 167 Forward Error Correction (FEC): FEC is a way of improving the 168 performance of high-capacity optical transmission systems. Employing 169 FEC in optical transmission systems yields system designs that can 170 accept relatively large BER (much more than 10^-12) in the optical 171 transmission line (before decoding). 173 Administrative domain [ITU-T.G.805]: the extent of resources which 174 belong to a single player such as a network operator, a service 175 provider or an end-user. Administrative domains of different players 176 do not overlap amongst themselves. 178 Intra-domain interface (IaDI) [ITU-T.G.872]: A physical interface 179 within an administrative domain. 181 Inter-domain interface (IrDI) [ITU-T.G.872]: A physical interface 182 that represents the boundary between two administrative domains. 184 Management Plane [ITU-T.G.8081],: The management plane performs 185 management functions for the transport plane, the control plane and 186 the system as a whole. It also provides coordination between all the 187 planes. The following management functional areas are performed in 188 the management plane: performance management, fault management, 189 configuration management, accounting management and security 190 management. 192 Control Plane [ITU-T.G.8081]: Through signaling, the control plane 193 sets up and releases connections, may restore a connection in case of 194 a failure, and also performs other functions (e.g., neighbor 195 discovery, topology distribution) in support of those. 197 Transponder: A Transponder is a network element that performs O/E/O 198 (Optical /Electrical/Optical) conversion. In this document it is 199 referred only transponders with 3R (rather than 2R or 1R 200 regeneration) as defined in [ITU-T.G.872]. 202 Line System: A Line System is a portion of the network including Add 203 Drop Multiplexers (ROADM) Line Amplifiers and the the fibers 204 connecting them. 206 Client DWDM interface: A Transceiver element that performs E/O 207 (Electrical/Optical) conversion. In this document it is referred as 208 the DWDM side of a transponder as defined in [ITU-T.G.872]. 210 3. Solution Space 212 The solution space of this document is focusing on aspects related to 213 the management and control of single-channel optical interface 214 parameters of physical point-to-point and ring DWDM applications on 215 single-mode optical fibres and allows the direct connection of a wide 216 variety of equipment using a DWDM link, for example 218 1. A digital cross-connect with multiple optical interfaces, 219 supplied by a different vendor from the line system 221 2. Devices as routing, switching or compute nodes, each from a 222 different vendor, providing optical line interfaces 224 3. A combination of the above 226 3.1. Comparison of Approaches for Transverse Compatibility 228 This section describes two ways to achieve transverse compatibility. 229 Section 3.1.1 describes the classic model based on well defined 230 inter-domain interfaces. Section 3.1.2 defines a model ensuring 231 interoperability on the line side of the optical network. 233 3.1.1. Multivendor DWDM Line System with Transponders 235 As illustrated in Figure 1, for this approach interoperability is 236 achieved via the use of optical transponders providing OEO (allowing 237 conversion to appropriate parameters). The optical interfaces can 238 then be any short reach standardized optical interface that both 239 vendors support, such as those found in [ITU-T.G.957], [ITU-T.G.691], 240 [ITU-T.G.693], etc. 242 IrDI IaDI 243 | | 244 . . 245 | +----------------------------|----+ 246 . | + WDM Domain + . | 247 | | |\ /| | | 248 +------+ . | | \ |\ / | . | +------+ 249 | TX/ |-->--+---+--T/-|OM|----|/-------|OD|--+-\T-+---->--| RX/ | 250 | RX |--<--+---+--T/-| |----- /|-----| |--.-\T-+----<--| TX | 251 +------+ | | | / \| \ | | | +------+ 252 . | |/ \| . | 253 | | + + | | 254 . +----------------------------.----+ 255 | | 257 TX/RX = Single channel non-DWDM interfaces 258 T/ = Transponder 259 OM = Optical Mux 260 OD = Optical Demux 262 Figure 1: Inter and Intra-Domain Interface Identification 264 In the scenario of Figure 1 the administrative domain is defined by 265 the Interdomain Interface (IrDI). This interface terminates the DWDM 266 domain. The line side is characterized by the IaDI. This interface 267 specifies the internal parameter set of the optical administrative 268 domain. In the case of a client DWDM interface deployment this 269 interface moves into the client device and extends the optical and 270 administrative domain towards the client node. [ITU-T.G.698.2] for 271 example specifies a set of parameter set for a certain set of 272 applications. 274 This document elaborates only the IaDI Interface as shown in Figure 1 275 as transversely compatible and multi-vendor interface within one 276 administrative domain controlled by the network operator. 278 SNMP/SMI, Yang models and LMP TLV to support the direct exchange of 279 information between the client and the network management and control 280 plane will be specified in further documents. 282 3.1.2. Integrated Single Channel DWDM Deployments on the Client Site 284 In case of a deployment as shown in Figure 2, through the use of DWDM 285 interfaces, multi-vendor interconnection can also be achieved. Among 286 the possible use cases, it may be used to remove the need for one 287 short reach transmitter and receiver pair per channel (eliminating 288 the transponders). 290 Figure 2 shows a set of reference points, for single-channel 291 connection (Ss and Rs) between transmitters (Tx) and receivers (Rx). 292 Here the DWDM network elements include an optical multiplexer (OM) 293 and an optical demultiplexer (OD) (which are used as a pair with the 294 peer element), one or more optical amplifiers and may also include 295 one or more OADMs. 297 |==================== Black Link =======================| 299 +-------------------------------------------------+ 300 Ss | | DWDM Network Elements | | Rs 301 +---+ | | | \ / | | | +---+ 302 Tx L1---|->| \ +------+ +------+ / |--|-->Rx L1 303 +---+ | | | | | +------+ | | | | | +---+ 304 +---+ | | | | | | | | | | | | +---+ 305 Tx L2---|->| OM |-|>|------|->| ROADM|--|------|->| OD |--|-->Rx L2 306 +---+ | | | | | | | | | | | | +---+ 307 +---+ | | | | | +------+ | | | | | +---+ 308 Tx L3---|->| / | DWDM | | ^ | DWDM | \ |--|-->Rx L3 309 +---+ | | / | Link +----|--|----+ Link | \ | | +---+ 310 +-----------+ | | +----------+ 311 +--+ +--+ 312 |==== Black Link ====| | | 313 v | 314 +-----+ +-----+ 315 |RxLx | |TxLx | 316 +-----+ +-----+ 318 Ss = Reference point at the DWDM network element tributary output 319 Rs = Reference point at the DWDM network element tributary input 320 Lx = Lambda x 321 OM = Optical Mux 322 OD = Optical Demux 323 ROADM = Reconfigurable Optical Add Drop Mux 325 Linear DWDM network as per ITU-T G.698.2 327 Figure 2: Linear Black Link 329 The single administrative domain may consist of several vendor 330 domains. Even in that case a common network management and control 331 is required to ensure a consistent operation and provisioning of the 332 entire connection. 334 SNMP/SMI, Yang models and LMP TLV to support the direct exchange of 335 information between the client and the network management and control 336 plane will be specified in further documents. 338 4. Solutions for Managing and Controlling Single Channel Optical 339 Interface 341 Operation and management of WDM systems is traditionally seen as a 342 homogenous group of tasks that could be carried out best when a 343 single management system or a hierarchical management system is used. 344 Currently each WDM vendor provides an Element Management System (EMS) 345 that also provisions the wavelengths. In a multi-vendor line system, 346 such single-vendor EMS requirement is no more effective. New methods 347 of managing and controlling line systems need to be looked at. 349 Therefore from the operational point of view the following approaches 350 will be considered to manage and operate optical interfaces. 352 1. Separate operation and management of client device and the 353 transport network whereas the interface of the client belongs to 354 the administrative domain of the transport network and will be 355 managed by the transport group. This results in two different 356 approaches to send information to the management system 358 a. Direct connection from the client node to the transport 359 management system, ensuring a management of the DWDM interface of 360 the optical network (e.g. EMS, NMS) 362 b. Indirect connection to the management system of the optical 363 network using a protocol (e.g. LMP) between the client device 364 and the directly connected WDM system node to exchange management 365 information with the optical domain 367 2. Common operation and management of client device including the 368 single channel DWDM part and the Transport network 370 The first option keeps the status quo in large carrier networks as 371 mentioned above. In that case it must be ensured that the full FCAPS 372 Management (Fault, Configuration, Accounting, Performance and 373 Security) capabilities are supported. This means from the management 374 staff point of view nothing changes. The transceiver/receiver 375 optical interface will be part of the optical management domain and 376 will be managed from the transport management staff. 378 The second solution addresses the case where underlying WDM transport 379 network is mainly used to interconnect a homogeneous set of client 380 nodes (e.g. IP routers or digital crossconnects). Since the service 381 creation and restoration could be done by the higher layers (e.g. 383 IP), this may lead to an efficient network operation and a higher 384 level of integration. 386 4.1. Separate Operation and Management Approaches 388 4.1.1. Direct Connection to the Management System 390 As depicted in Figure 3 (case 1a) one possibility to manage the 391 optical interface within the client domain is a direct connection to 392 the management system of the optical domain. This ensures 393 manageability as usual. 395 +-----+ 396 | NMS | 397 |_____| 398 /_____/ 399 | 400 | 401 | 402 +---+---+ 403 +----->+ EMS | 404 / | | 405 / +-------+ 406 / | MI SNMP or Yang 407 SNMP / or Yang | DCN Network 408 --------------------+------------------------------- 409 / +------+-----------------------+ 410 / | +| WDM Domain + | 411 / | |\ /| | 412 +---+--+ | | \ |\ / | | +------+ 413 | CL |-/C------+-----|OM|----|/-------|OD|----+-------/C-| CL | 414 | |-/C------+-----| |----- /|-----| |----+-------/C-| | 415 +------+ | | / \| \ | | +------+ 416 | |/ \| | 417 | + + | 418 +------------------------------+ 420 CL = Client Device 421 /C = Single Channel Optical Interface 422 OM = Optical Mux 423 OD = Optical Demux 424 EMS = Element Management System 425 MI = Management Interface 426 DCN = Data Control Network 428 Figure 3: Connecting Single Channel optical interfaces to the 429 Transport Management system 431 The exchange of management information between client device and the 432 management system assumes that some form of a direct management 433 communication link exists between the client device and the DWDM 434 management system (e.g. EMS). This may be an Ethernet Link or a DCN 435 connection (management communication channel MCC). 437 It must be ensured that the optical network interface can be managed 438 in a standardized way to enable interoperable solutions between 439 different optical interface vendors and vendors of the optical 440 network management application. [RFC3591] defines managed objects 441 for the optical interface type but needs further extension to cover 442 the optical parameters required by this framework document. 444 Note that a software update of the optical interface components of 445 the client nodes must not lead obligatory to an update of the 446 software of the EMS and vice versa. 448 4.1.2. Indirect Connection to the DWDM Management System (First Optical 449 Node) 451 An alternative as shown in Figure 4 should be used in cases where a 452 more integrated relationship between transport node (e.g. OM or OD 453 or ROADM) and client device is aspired. In that case a combination 454 of control plane features and manual management will be used. 456 +-----+ 457 | NMS | 458 |_____| 459 /_____/ 460 | 461 | 462 +---+---+ 463 | EMS | 464 | | 465 +-------+ 466 | MI SNMP or Yang 467 | 468 LMP +------+-----------------------+ 469 +------------+---+ +| + | 470 | | | |\ /| | 471 +---+--+ | +-+ \ |\ / | | +------+ 472 | CL |-/C------+--- -|OM|----|/-------|OD|--- +-------/C-| CL | 473 | |-/C------+--- -| |----- /|-----| |----+-------/C-| | 474 +------+ | | / \| \ | | +------+ 475 | |/ \| | 476 | + + | 477 +------------------------------+ 479 CL = Client Device 480 /C = Single Channel optical Interface 481 OM = Optical Mux 482 OD = Optical Demux 483 EMS= Element Management System 484 MI= Management Interface 486 Figure 4: Direct connection between peer node and first optical 487 network node 489 For information exchange between the client node and the direct 490 connected node of the optical transport network LMP as specified in 491 RFC 4209 [RFC4209] should be used. This extension of LMP may be used 492 between a peer node and an adjacent optical network node as depicted 493 in Figure 4. 495 At the time of writing this document, LMP does not yet support the 496 transmission of configuration data (information). This functionality 497 must be added to the protocol. The use of LMP assumes that some form 498 of a control channel exists between the client node and the WDM 499 equipment. This may be a dedicated lambda or an Ethernet Link. 501 4.2. Control Plane Considerations 503 The concept of integrated single channel DWDM interfaces equally 504 applies to management and control plane mechanisms. GMPLS control 505 plane protocols have been extended for WSON, e.g. RFC 7689 [RFC7689] 506 ) for fixed grid signal and for flexi-grid RFC 7792 [RFC7792] ). One 507 important aspect of the Black Link [ITU-T.G.698.2] is the fact that 508 it includes the wavelength that is supported by the given link. 509 Therefore, the link can logically be considered as a fiber that is 510 transparent only for a single wavelength. In other words, the 511 wavelength becomes a characteristic of the link itself. 513 Nevertheless the procedure to light up the fiber may vary depending 514 on the implementation. Since the implementation is unknown a priori, 515 different sequences to light up a wavelength need to be considered: 517 1. Interface first, interface tuning: The transmitter is switched on 518 and the link is immediately transparent to its wavelength. This 519 requires the transmitter to carefully tune power and frequency 520 not overload the line system or to create transients. 522 2. Interface first, OLS tuning: The transmitter is switched on first 523 and can immediately go to the max power allowed since the OLS 524 performs the power tuning. This leads to an intermediate state 525 where the receiver does not receive a valid signal while the 526 transmitter is sending out one. Alarm suppression mechanisms 527 shall be employed to overcome that condition. 529 3. OLS first, interface tuning: At first the OLS is tuned to be 530 transparent for a given wavelength, then transponders need to be 531 tuned up. Since the OLS in general requires the presence of a 532 wavelength to fine-tune its internal facilities there may be a 533 period where a valid signal is transmitted but the receiver is 534 unable to detect it. This equally need to be covered by alarm 535 suppression mechanisms. 537 4. OLS first, OLS tuning: The OLS is programmed to be transparent 538 for a given wavelength, then the interfaces need to be switched 539 on and further power tuning takes place. The sequencing of 540 enabling the link needs to be covered as well. 542 The preferred way to address these in a Control Plane enabled network 543 is neighbour discovery including exchange of link characteristics and 544 link property correlation. The general mechanisms are covered in RFC 545 4209 [RFC4209] and RFC 4204 [RFC4204] which provides the necessary 546 protocol framework to exchange those characteristics between client 547 and Black Link. LMP-WDM is not intended for exchanging routing or 548 signaling information nor to provision the lambda in the transceiver 549 but covers: 551 1. Control channel management 553 2. Link property correlation 555 3. Link verification 557 4. Fault management 559 Extensions to LMP covering the parameter sets (e.g. application 560 codes) are needed. Additionally, when client and server side are 561 managed by different operational entities, the link state may be 562 useful to help the management system to do troubleshooting or alarm 563 correlation. 565 4.2.1. Considerations Using GMPLS Signaling 567 The deployment of single channel optical interfaces is leading to 568 some functional changes related to the control plane models and has 569 therefore some impact on the existing interfaces especially in the 570 case of a model where the edge node requests resources from the core 571 node and the edge node do not participate in the routing protocol 572 instance that runs among the core nodes. RFC 4208 [RFC4208] defines 573 the GMPLS UNI that can be used between edge and core node. In case 574 of integrated interfaces deployment additional functionalities are 575 needed to setup a connection. 577 It is necessary to differentiate between topology/signalling 578 information and configuration parameters that are needed to setup a 579 wavelength path. Using RSVP-TE could be used for the signalling and 580 the reservation of the wavelength path. But there are additional 581 information needed before RSVP-TE can start the signalling process. 582 There are three possibilities to proceed: 584 a. Using RSVP-TE only for the signalling and LMP as described above 585 to exchange information on the configured optical interface 586 within the edge node 588 b. RSVP-TE (typically with loose ERO) to transport additional 589 information 591 c. Leaking IGP information instead of exchanging this information 592 needed from the optical network to the edge node (UNI will be 593 transformed to a border-peer model, see RFC 5146 [RFC5146] ) 595 Furthermore following issues should be addressed: 597 a) The transceivers of peering edge nodes must be compatible. For 598 example, it may be required to know about FEC, modulation scheme, 599 etc. Depending on where the information is available, compatibility 600 check may either happen before signaling, when the signaling reaches 601 the optical network (e.g. at path computation time), or in the tail 602 end node. An extended version of LMP is needed to exchange this 603 information in case a. above, and to RSVP-TE as well in b. It would 604 be helpful to define some common profiles that will be supported 605 (e.g. the "application identifier") to summarize interface 606 capabilities: if both profiles match, signaling can succeed and 607 provisioning be achieved. 609 b) Due to the bidirectional wavelength path that must be setup, the 610 upstream edge node must include a wavelength value into the RSVP-TE 611 Path message. But in the case of a UNI model the client device may 612 not have full information about which wavelength must/should be 613 selected, whereas this information must be exchanged between the edge 614 and the core node. The special value defined in 615 [Network-Assigned-Upstream-Label] allows the optical network to 616 assign the actual wavelength to be used by the upstream transponder, 617 which is a simple and efficient solution to this issue. 619 5. Use Cases 621 A comparison with the traditional operation scenarios provides an 622 insight of similarities and distinctions in operation and management 623 of DWDM interfaces. The following use cases provide an overview 624 about operation and maintenance processes. 626 5.1. Service Setup 628 It is necessary to differentiate between different operational issues 629 for setting up a light path (a DWDM connection is specific in having 630 defined maximum impairments) within an operational network. 632 The first step is to determine if transceivers located at different 633 end-points are interoperable, i.e. support a common set of 634 operational parameters. In this step it is required to determine 635 transceiver capabilities in a way to be able to correlate them for 636 interoperability purposes. Such parameters include modulation 637 scheme, modulation parameters, FEC to name a few. If both 638 transceivers are controlled by the same NMS or CP, such data is 639 readily available. However in cases like Figure 4, a protocol needs 640 to be used to inform the controlling instance (NMS or CP) about 641 transceiver parameters. It is suggested to extend LMP for that 642 purpose. 644 The second step is to determine the feasibility of a lightpath 645 between two transceivers without applying an optical signal. 646 Understanding the limitations of the transceiver pair, a path through 647 tho optical network has to be found, whereby each path has an 648 individual set of impairments deteriorating a wavelength traveling 649 along that path. Since a single transceiver can support multiple 650 parameter sets, the selection of a path may limit the permissible 651 parameter sets determined in previous steps. 653 The third step is then to setup the connection itself and to 654 determine the Wavelength. This is done using the NMS of the optical 655 transport network or by means of a control plane interaction such as 656 signaling and includes the path information as well as the parameter 657 set information necessary to enable communication. 659 In a fourth step, optical monitoring is activated in the WDM network 660 in order to monitor the status of the connection. The monitor 661 functions of the optical interfaces at the terminals are also 662 activated in order to monitor the end to end connection. 664 Furthermore it should be possible to automate this step. After 665 connecting the client device to the neighbor control plane-enabled 666 transport node, a control adjacency may be automatically established, 667 e.g. using LMP. 669 5.2. Link Monitoring Use Cases 671 The use cases described below are assuming that power monitoring 672 functions are available in the ingress and egress network element of 673 the DWDM network, respectively. By performing link property 674 correlation it would be beneficial to include the current transmit 675 power value at reference point Ss and the current received power 676 value at reference point Rs. For example if the Client transmitter 677 power has a value of 0dBm and the ROADM interface measured power is 678 -6dBm the fiber patch cord connecting the two nodes may be pinched or 679 the connectors are dirty. As discussed before, the actual path or 680 selection of a specific wavelength within the allowed set is outside 681 the scope of LMP. The computing entities (e.g. the first optical 682 node originating the circuit) can rely on GMPLS IGP (OSPF) to 683 retrieve all the information related to the network, calculate the 684 path to reach the endpoint and signal the path implementation through 685 the network via RSVP-TE. 687 [ITU-T.G.698.2] defines a single channel optical interface for DWDM 688 systems that allows interconnecting network-external optical 689 transponders across a DWDM network. The optical transponders are 690 external to the DWDM network. This so-called 'Black Link' approach 691 illustrated in Fig. 5-1 of [ITU-T.G.698.2] and a copy of this figure 692 is provided below in Figure 5. The single channel fiber link between 693 the Ss/Rs reference points and the ingress/egress port of the network 694 element on the domain boundary of the DWDM network (DWDM border NE) 695 is called access link. Based on the definition in [ITU-T.G.698.2] it 696 is part of the DWDM network. The access link is typically realized 697 as a passive fiber link that has a specific optical attenuation 698 (insertion loss). As the access link is an integral part of the DWDM 699 network, it is desirable to monitor its attenuation. Therefore, it 700 is useful to detect an increase of the access link attenuation, for 701 example, when the access link fiber has been disconnected and 702 reconnected (maintenance) and a bad patch panel connection 703 (connector) resulted in a significantly higher access link 704 attenuation (loss of signal in the extreme case of an open connector 705 or a fiber cut). In the following section, two use cases are 706 presented and discussed: 708 1) pure access link monitoring 709 2) access link monitoring with a power control loop 711 These use cases require a power monitor as described in G.697 (see 712 section 6.1.2), that is capable to measure the optical power of the 713 incoming or outgoing single channel signal. The use case where a 714 power control loop is in place could even be used to compensate an 715 increased attenuation if the optical transmitter can still be 716 operated within its output power range defined by its application 717 code. 719 Use case 1: Access Link monitoring 721 +--------------------------+ 722 | P(in) = P(Tx) - a(Tx) | 723 | ___ | 724 +----------+ | \ / Power Monitor | 725 | | P(Tx) | V P(in) | 726 | +----+ | Ss //\\ | | |\ | 727 | | TX |----|-----\\//------------------->| \ | 728 | +----+ | Access Link (AL-T) | . | | | 729 | | attenuation a(Tx) | . | |==============> 730 | | | . | | | 731 | External | | --->| / | 732 | Optical | | |/ | 733 |Transpond.| | P(out) | 734 | | | ___ | 735 | | | \ / Power Monitor | 736 | | P(Rx) | V P(out) | 737 | +----+ | Rs //\\ | | |\ | 738 | | RX |<---|-----\\//--------------------| \ | 739 | +----+ | Access Link (AL-R) | . | | | 740 | | Attenuation a(Rx) | . | |<============== 741 +----------+ | . | | | 742 | <---| / | 743 P(Rx) = P(out) - a(Rx) | |/ | 744 | | 745 | ROADM | 746 +--------------------------+ 748 - For AL-T monitoring: P(Tx) and a(Tx) must be known 749 - For AL-R monitoring: P(RX) and a(Rx) must be known 751 An alarm shall be raised if P(in) or P(Rx) drops below a 752 configured threshold (t [dB]): 753 - P(in) < P(Tx) - a(Tx) - t (Tx direction) 754 - P(Rx) < P(out) - a(Rx) - t (Rx direction) 755 - a(Tx) =| a(Rx) 757 Alarms and events can be shared between Client and Network 758 via LMP. 760 Figure 5: Access Link Power Monitoring 762 5.2.1. Pure Access Link (AL) Monitoring Use Case 764 Figure 6 illustrates the access link monitoring use case and the 765 different physical properties involved that are defined below: 767 - Ss, Rs: Single Channel reference points 768 - P(Tx): current optical output power of transmitter Tx 769 - a(Tx): access link attenuation in Tx direction (external 770 transponder point of view) 771 - P(in): measured current optical input power at the input port 772 of border DWDM NE 773 - t: user defined threshold (tolerance) 774 - P(out): measured current optical output power at the output port 775 of border DWDM NE 776 - a(Rx): access link attenuation in Rx direction (external 777 transponder point of view) 778 - P(Rx): current optical input power of receiver Rx 780 Description: 781 - The access link attenuation in both directions (a(Tx), a(Rx)) 782 is known or can be determined as part of the commissioning 783 process. Typically, both values are very similar. 784 - A threshold value t has been configured by the operator. This 785 should also be done during commissioning. 786 - A control plane protocol is in place that allows 787 to periodically send the optical power values P(Tx) and P(Rx) 788 to the control plane protocol instance on the DWDM border NE. 789 This is illustrated in Figure 3. 790 - The DWDM border NE is capable to periodically measure the optical 791 power Pin and Pout as defined in G.697 by power monitoring points 792 depicted as yellow triangles in the figures below. 794 Access Link monitoring process: 795 - Tx direction: the measured optical input power Pin is compared 796 with the expected optical input power P(Tx) - a(Tx). If the 797 measured optical input power P(in) drops below the value 798 (P(Tx) - a(Tx) - t) a low power alarm shall be raised indicating 799 that the access link attenuation has exceeded a(Tx) + t. 800 - Rx direction: the measured optical input power P(Rx) is 801 compared with the expected optical input power P(out) - a(Rx). 802 If the measured optical input power P(Rx) drops below the value 803 (P(out) - a(Rx) - t) a low power alarm shall be raised indicating 804 that the access link attenuation has exceeded a(Rx) + t. 805 - to avoid toggling errors, the low power alarm threshold shall be 806 lower than the alarm clear threshold. 808 Use case 1: Access Link monitoring 810 +----------+ +--------------------------+ 811 | +------+ | P(Tx), P(Rx) | +-------+ | 812 | | | | =================> | | | | 813 | | LMP | | P(in), P(out) | | LMP | | 814 | | Agent| | <================= | | Agent | | 815 | +------+ | | +-------+ | 816 | | | | 817 | | | P(in) - P(Tx) - a(Tx) | 818 | | | ___ | 819 | | | \ / Power Monitor | 820 | | P(Tx) | V | 821 | +----+ | Ss //\\ | | |\ | 822 | | TX |----|-----\\//------------------->| \ | 823 | +----+ | Access Link (AL-T) | . | | | 824 | | attenuation a(Tx) | . | |==============> 825 | | | . | | | 826 | External | | --->| / | 827 | Optical | | |/ | 828 |Transpond.| | P(out) | 829 | | | ___ | 830 | | | \ / Power Monitor | 831 | | P(Rx) | V | 832 | +----+ | Rs //\\ | | |\ | 833 | | RX |<---|-----\\//--------------------| \ | 834 | +----+ | Access Link (AL-R) | . | | | 835 | | Attenuation a(Rx) | . | |<============== 836 +----------+ | . | | | 837 | <---| / | 838 P(Rx) = P(out) - a(Rx) | |/ | 839 | | 840 | ROADM | 841 +--------------------------+ 843 - For AL-T monitoring: P(Tx) and a(Tx) must be known 844 - For AL-R monitoring: P(RX) and a(Rx) must be known 845 An alarm shall be raised if P(in) or P(Rx) drops below a 846 configured threshold (t [dB]): 847 - P(in) < P(Tx) - a(Tx) - t (Tx direction) 848 - P(Rx) < P(out) - a(Rx) - t (Rx direction) 849 - a(Tx) = a(Rx) 851 Alarms and events can be shared between Client and Network 852 via LMP according to [RFC4204] and [RFC4209] 853 Figure 6: Extended LMP Model 855 5.2.2. Power Control Loop Use Case 857 This use case is based on the access link monitoring as 858 described above. In addition, the border NE is running a power 859 control application that is capable to control the optical output 860 power of the single channel tributary signal at the output port 861 of the border DWDM NE (towards the external receiver Rx) and the 862 optical output power of the single channel tributary signal at 863 the external transmitter Tx within their known operating range. 864 The time scale of this control loop is typically relatively slow 865 (e.g. some 10s or minutes) because the access link attenuation 866 is not expected to vary much over time (the attenuation only 867 changes when re-cabling occurs). 868 From a data plane perspective, this use case does not require 869 additional data plane extensions. It does only require a protocol 870 extension in the control plane (e.g. this LMP draft) that allows 871 the power control application residing in the DWDM border NE to 872 modify the optical output power of the DWDM domain-external 873 transmitter Tx within the range of the currently used application 874 code. Figure 7 below illustrates this use case utilizing 875 LMP with the extensions identified in this document. 877 Use case 2: Power Control Loop 879 +----------+ +--------------------------+ 880 | +------+ | P(Tx),P(Rx),Set(Pout) | +-------+ +--------+ | 881 | | | | ====================> | | | | Power | | 882 | | LMP | | P(in),P(out),Set(PTx) | | LMP | |Control | | 883 | | | | <==================== | | | | Loop | | 884 | +------+ | | +-------+ +--------+ | 885 | | | | | 886 | +------+ | | P(in) = P(Tx) - a(Tx) | 887 | |C.Loop| | | ___ | 888 | +------+ | | \ / Power Monitor | 889 | | | P(Tx) | V | 890 | +------+ | Ss //\\ | | |\ | 891 | | TX |>----|-----\\//---------------------->| \ | 892 | +------+ | Access Link (AL-T) | . | | | 893 | VOA(Tx) | attenuation a(Tx) | . | |==============> 894 | | | . | | | 895 | External | | --->| / | 896 | Optical | | |/ | 897 |Transpond.| | P(out) | 898 | | | ___ | 899 | | | \ / Power Monitor | 900 | | P(Rx) | V | 901 | +----+ | Rs //\\ | | VOA(out) |\ | 902 | | RX |<---|-----\\//---------------------<|-------| \ | 903 | +----+ | Access Link (AL-R) | . | | | 904 | | attenuation a(Rx) | . | |<======= 905 +----------+ | VOA(out) | | | 906 | <--<|-------| / | 907 P(Rx) = P(out) - a(Rx) | |/ | 908 | | 909 | ROADM | 910 +--------------------------+ 912 Figure 7: Power control loop 914 - The power control loop in transponders and ROADMs controls 915 the Variable Optical Attenuators (VOA) to adjust the proper 916 power in base of the ROADM and Receiver caracteristics and 917 the Access Link attenuation 919 6. Requirements 921 Even if network architectures becomes more complex, management and 922 operation as well as the provisioning process should have a higher 923 degree of automation or should be fully automated. Simplifying and 924 automating the entire management and provisioning process of the 925 network in combination with a higher link utilization and faster 926 restoration times will be the major requirements that have been 927 addressed in this section. 929 Data plane interoperability as defined for example in [ITU-T.G.698.2] 930 is a precondition to take full benefit from standardized interfaces 931 between network and control/management plane. 933 The following requirements are focusing on the usage of DWDM 934 interfaces. 936 1 A standardized procedure to setup an optical connection MUST 937 be defined and implemented in DWDM and client devices 938 (containing the single channel optical interface). 940 2 In order to ensure a lean management and provisioning of single 941 channel interfaces, the management and control plane of both the 942 client and DWDM network MUST be aware of the right set of 943 parameters. Such parameters define the interfaces and the optical 944 network and are needed to properly setup the optical connection. 946 3 A standard-based northbound API (to network management system) 947 based on Netconf SHOULD be supported, alternatively SNMP MAY 948 be supported too. 950 4 A standard-based data model for single channel interfaces MUST be 951 supported to exchange optical parameters with control/management 952 plane. 954 5 Netconf SHOULD be used also for configuration of the single 955 channel interfaces including the power setting 957 6 LMP SHOULD be extended and used in cases where optical 958 parameters need to be exchanged between two nodes to correlate 959 link characteristics and adopt the working mode of the single 960 channel interface. 962 7 LMP MAY be used to adjust the output power of the single 963 channel DWDM interface to ensure that the interface works in 964 the right range. 966 8 RSVP-TE SHOULD be used to exchange some relevant parameters 967 between the client and the optical node (e.g. the label value), 968 without preventing the network to remain in charge of the optical 969 path computation 971 9 Power monitoring functions at both ends of the DWDM connection 972 MAY be used to further automate the setup and shoutdown 973 process of the optical interfaces. 975 10 In fault cases, the network SHOULD be able to recover wavelengths, 976 either using pre-defined paths or dynamic re-routing. 978 11 LMP MAY be used to monitor and observe the access link. 980 7. Acknowledgements 982 The authors would like to thank all who supported the work with 983 fruitful discussions and contributions. 985 8. IANA Considerations 987 This memo includes no request to IANA. 989 9. Security Considerations 991 The architecture and solution space in scope of this framework 992 imposes no additional requirements to the security models already 993 defined in RFC5920 for packet/optical networks using GMPLS, covering 994 also Control Plane and Management interfaces. Respective security 995 mechanisms of the components and protocols, e.g. LMP security 996 models, can be applied unchanged. 998 As this framework is focusing on the single operator use case, the 999 security concerns can be relaxed to a subset compared to a setup 1000 where information is exchanged between external parties and over 1001 external interfaces. 1003 Concerning the access control to Management interfaces, security 1004 issues can be generally addressed by authentication techniques 1005 providing origin verification, integrity and confidentiality. 1006 Additionally, access to Management interfaces can be physically or 1007 logically isolated, by configuring them to be only accessible out-of- 1008 band, through a system that is physically or logically separated from 1009 the rest of the network infrastructure. In case where management 1010 interfaces are accessible in-band at the client device or within the 1011 optical transport netork domain, filtering or firewalling techniques 1012 can be used to restrict unauthorized in-band traffic. Authentication 1013 techniques may be additionally used in all cases. 1015 10. Contributors 1016 Arnold Mattheus 1017 Deutsche Telekom 1018 Darmstadt 1019 Germany 1020 email arnold.Mattheus@telekom.de 1022 Manuel Paul 1023 Deutsche Telekom 1024 Berlin 1025 Germany 1026 email Manuel.Paul@telekom.de 1028 Josef Roese 1029 Deutsche Telekom 1030 Darmstadt 1031 Germany 1032 email j.roese@telekom.de 1034 Frank Luennemann 1035 Deutsche Telekom 1036 Muenster 1037 Germany 1038 email Frank.Luennemann@telekom.de 1040 11. References 1042 11.1. Normative References 1044 [ITU-T.G.694.1] 1045 International Telecommunications Union, "Spectral grids 1046 for WDM applications: DWDM frequency grid", 1047 ITU-T Recommendation G.694.1, Febriary 2012. 1049 [ITU-T.G.698.2] 1050 International Telecommunications Union, "Amplified 1051 multichannel dense wavelength division multiplexing 1052 applications with single channel optical interfaces", 1053 ITU-T Recommendation G.698.2, November 2009. 1055 [ITU-T.G.805] 1056 International Telecommunications Union, "Spectral grids 1057 for WDM applications: DWDM frequency grid", 1058 ITU-T Recommendation G.805, March 2000. 1060 [ITU-T.G.872] 1061 International Telecommunications Union, "Architecture of 1062 optical transport networks", ITU-T Recommendation G.872, 1063 November 2001. 1065 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1066 Requirement Levels", BCP 14, RFC 2119, 1067 DOI 10.17487/RFC2119, March 1997, 1068 . 1070 [RFC3591] Lam, H-K., Stewart, M., and A. Huynh, "Definitions of 1071 Managed Objects for the Optical Interface Type", RFC 3591, 1072 DOI 10.17487/RFC3591, September 2003, 1073 . 1075 [RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC 4204, 1076 DOI 10.17487/RFC4204, October 2005, 1077 . 1079 [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, 1080 "Generalized Multiprotocol Label Switching (GMPLS) User- 1081 Network Interface (UNI): Resource ReserVation Protocol- 1082 Traffic Engineering (RSVP-TE) Support for the Overlay 1083 Model", RFC 4208, DOI 10.17487/RFC4208, October 2005, 1084 . 1086 [RFC4209] Fredette, A., Ed. and J. Lang, Ed., "Link Management 1087 Protocol (LMP) for Dense Wavelength Division Multiplexing 1088 (DWDM) Optical Line Systems", RFC 4209, 1089 DOI 10.17487/RFC4209, October 2005, 1090 . 1092 [RFC7689] Bernstein, G., Ed., Xu, S., Lee, Y., Ed., Martinelli, G., 1093 and H. Harai, "Signaling Extensions for Wavelength 1094 Switched Optical Networks", RFC 7689, 1095 DOI 10.17487/RFC7689, November 2015, 1096 . 1098 [RFC7792] Zhang, F., Zhang, X., Farrel, A., Gonzalez de Dios, O., 1099 and D. Ceccarelli, "RSVP-TE Signaling Extensions in 1100 Support of Flexi-Grid Dense Wavelength Division 1101 Multiplexing (DWDM) Networks", RFC 7792, 1102 DOI 10.17487/RFC7792, March 2016, 1103 . 1105 11.2. Informative References 1107 [ITU-T.G.691] 1108 ITU-T, "Optical interfaces for single channel STM-64 and 1109 other SDH systems with optical amplifiers", 1110 ITU-T Recommendation ITU-T G.691, 2008. 1112 [ITU-T.G.693] 1113 ITU-T, "Optical interfaces for intra-office systems", 1114 ITU-T Recommendation ITU-T G.693, 2009. 1116 [ITU-T.G.8081] 1117 ITU-T, "Terms and definitions for Automatically Switched 1118 Optical Networks (ASON)", ITU-T Recommendation G.8081", 1119 ITU-T Recommendation ITU-T G.8081, September 2010. 1121 [ITU-T.G.957] 1122 ITU-T, "Optical interfaces for equipments and systems 1123 relating to the synchronous digital hierarchy", 1124 ITU-T Recommendation ITU-T G.957, 2006. 1126 [Network-Assigned-Upstream-Label] 1127 Internet Engineering Task Force, "Generalized Multi- 1128 Protocol Label Switching (GMPLS) Resource reSerVation 1129 Protocol with Traffic Engineering (RSVP- TE) mechanism 1130 that enables the network to assign an upstream label for a 1131 bidirectional LSP", draft-ietf-teas-network-assigned- 1132 upstream-label draft-ietf-teas-network-assigned-upstream- 1133 label, June 2017. 1135 [RFC5146] Kumaki, K., Ed., "Interworking Requirements to Support 1136 Operation of MPLS-TE over GMPLS Networks", RFC 5146, 1137 DOI 10.17487/RFC5146, March 2008, 1138 . 1140 Authors' Addresses 1142 Ruediger Kunze (editor) 1143 Deutsche Telekom 1144 Winterfeldtstr. 21-27 1145 10781 Berlin 1146 Germany 1148 Phone: +491702275321 1149 Email: RKunze@telekom.de 1150 Gert Grammel (editor) 1151 Juniper 1152 Oskar-Schlemmer Str. 15 1153 80807 Muenchen 1154 Germany 1156 Phone: +49 1725186386 1157 Email: ggrammel@juniper.net 1159 Dieter Beller 1160 Nokia 1161 Lorenzstrasse, 10 1162 70435 Stuttgart 1163 Germany 1165 Phone: +4971182143125 1166 Email: Dieter.Beller@nokia.com 1168 Gabriele Galimberti (editor) 1169 Cisco 1170 Via S. Maria Molgora, 48c 1171 20871 - Vimercate 1172 Italy 1174 Phone: +390392091462 1175 Email: ggalimbe@cisco.com 1177 Julien Meuric 1178 Orange 1179 2, Avenue Pierre Marzin 1180 22307 Lannion Cedex 1181 France 1183 Phone: +33 1184 Email: julien.meuric@orange.com