idnits 2.17.1 draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 13, 2017) is 2599 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'ITU-T G.694.1' is mentioned on line 172, but not defined == Missing Reference: 'G.805' is mentioned on line 182, but not defined == Missing Reference: 'G.872' is mentioned on line 191, but not defined == Missing Reference: 'G.8081' is mentioned on line 202, but not defined == Missing Reference: 'ITU-T G.957' is mentioned on line 248, but not defined == Missing Reference: 'ITU-T G.691' is mentioned on line 248, but not defined == Missing Reference: 'ITU-T G.693' is mentioned on line 249, but not defined == Missing Reference: 'ITU-T G.959.1' is mentioned on line 249, but not defined == Missing Reference: 'YANG' is mentioned on line 450, but not defined == Missing Reference: 'LMP' is mentioned on line 551, but not defined == Missing Reference: 'LMP-WDM' is mentioned on line 551, but not defined == Missing Reference: 'RFC4208' is mentioned on line 576, but not defined == Unused Reference: 'RFC2863' is defined on line 1039, but no explicit reference was found in the text == Unused Reference: 'RFC2578' is defined on line 1048, but no explicit reference was found in the text == Unused Reference: 'RFC2579' is defined on line 1054, but no explicit reference was found in the text == Unused Reference: 'RFC2580' is defined on line 1059, but no explicit reference was found in the text == Unused Reference: 'RFC6205' is defined on line 1069, but no explicit reference was found in the text == Unused Reference: 'ITU.G709' is defined on line 1086, but no explicit reference was found in the text == Unused Reference: 'ITU-TG.691' is defined on line 1104, but no explicit reference was found in the text == Unused Reference: 'ITU-TG.693' is defined on line 1109, but no explicit reference was found in the text == Unused Reference: 'ITU-TG.957' is defined on line 1113, but no explicit reference was found in the text == Unused Reference: 'ITU-TG.959.1' is defined on line 1123, but no explicit reference was found in the text == Unused Reference: 'ITU-TG.8081' is defined on line 1127, but no explicit reference was found in the text -- No information found for draft-galimkunze-ccamp-dwdm-if-snmp-mib - is the name correct? Summary: 0 errors (**), 0 flaws (~~), 25 warnings (==), 2 comments (--). 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: September 14, 2017 Juniper 6 D. Beller 7 Nokia 8 G. Galimberti, Ed. 9 Cisco 10 March 13, 2017 12 A framework for Management and Control of DWDM optical interface 13 parameters 14 draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-04 16 Abstract 18 To ensure an efficient data transport, meeting the requirements 19 requested by today's IP-services the control and management of DWDM 20 interfaces is a precondition for enhanced multilayer networking and 21 for an further automation of network provisioning and operation. 22 This document describes use cases and requirements for the control 23 and management of optical interfaces parameters according to 24 different types of single channel DWDM interfaces. The focus is on 25 automating the network provisioning process irrespective on how it is 26 triggered i.e. by EMS, NMS or GMPLS. This document covers management 27 as well as control plane considerations in different management cases 28 of single channel DWDM interfaces. The purpose is to identify the 29 necessary information elements and processes to be used by control or 30 management systems for further processing. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on September 14, 2017. 49 Copyright Notice 51 Copyright (c) 2017 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 68 2. Terminology and Definitions . . . . . . . . . . . . . . . . . 4 69 3. Solution Space . . . . . . . . . . . . . . . . . . . . . . . 5 70 3.1. Comparison of approaches for transverse compatibility . . 6 71 3.1.1. Multivendor DWDM line system with transponders . . . 6 72 3.1.2. Integrated single channel DWDM deployments on the 73 client site . . . . . . . . . . . . . . . . . . . . . 7 74 4. Solutions for managing and controlling single channel optical 75 interface . . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 4.1. Separate Operation and Management Approaches . . . . . . 10 77 4.1.1. Direct connection to the management system . . . . . 10 78 4.1.2. Direct connection to the DWDM management system . . . 11 79 4.2. Control Plane Considerations . . . . . . . . . . . . . . 13 80 4.2.1. Considerations using GMPLS UNI . . . . . . . . . . . 14 81 5. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 15 82 5.1. Service Setup . . . . . . . . . . . . . . . . . . . . . . 15 83 5.2. Link monitoring Use Cases . . . . . . . . . . . . . . . . 16 84 5.2.1. Pure Access Link (AL) Monitoring Use Case . . . . . . 18 85 5.2.2. Power Control Loop Use Case . . . . . . . . . . . . . 21 86 6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 23 87 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 88 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 89 9. Security Considerations . . . . . . . . . . . . . . . . . . . 25 90 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25 91 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 92 11.1. Normative References . . . . . . . . . . . . . . . . . . 26 93 11.2. Informative References . . . . . . . . . . . . . . . . . 27 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 96 1. Introduction 98 The usage of the single channel DWDM interfaces (e.g. in routers) 99 connected to a DWDM Network (which include ROADMs and optical 100 amplifiers) adds a further networking option for operators allowing 101 new scenarios and requiring more control/management plane 102 integration. 104 Carriers deploy their networks today as a combination of transport 105 and packet infrastructures to ensure high availability and flexible 106 data transport. Both network technologies are usually managed by 107 different operational units using different management concepts. 108 This is the status quo in many carrier networks today. In the case 109 of deployments, where the optical transport interface moves into the 110 client device (e.g. , router), it is necessary to coordinate the 111 management of the optical interface at the client domain with the 112 optical transport domain. There are different levels of 113 coordination, which are specified in this framework. 115 The objective of this document is to provide a framework that 116 describes the solution space for the control and management of single 117 channel interfaces and providing use cases on how to manage these 118 solutions. In particular, it examines topological elements and 119 related network management measures. From an architectural point of 120 view, the network can be considered as a set of pre- configured/ 121 qualified unidirectional, single-fiber, network connections between 122 reference points S and R shown in figure 2. The optical transport 123 network is managed and controlled in order to provide optical 124 connections at the intended centre frequencies and the optical 125 interfaces are managed and controlled to generate signals of the 126 intended centre frequencies and further parameters as specified for 127 example in ITU-T Recommendations G.698.2 and G.798. The management 128 or control plane of the client and DWDM network is aware of the 129 parameters of the interfaces to properly set up the optical link. 130 This knowledge can be used furthermore, to support fast fault 131 detection. 133 Optical routing and wavelength assignment based on WSON is out of 134 scope although can benefit of the way the optical parameters are 135 exchanged between the Client and the DWDM Network. 137 Additionally, the wavelength ordering process and the process how to 138 determine the demand for a new wavelength from A to Z is out of 139 scope. 141 Note that the Control and Management Planes are two separate entities 142 that are handling the same information in different ways. This 143 document covers management as well as control plane considerations in 144 different management cases of single channel DWDM interfaces. 146 1.1. Requirements Language 148 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 149 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 150 document are to be interpreted as described in RFC 2119 [RFC2119]. 152 2. Terminology and Definitions 154 The current generation of WDM netwoks are single vendor networks 155 where the optical line system and the transponders are tightly 156 integrated. The DWDM interfaces migration from the transponders to 157 the colored interfaces changes this scenario, by introducing a 158 standardized interface at the level of OCh between the DWDM interface 159 and the DWDM network. 161 Black Link: The Black Link [ITU.G698.2] allows supporting an optical 162 transmitter/receiver pair of a single vendor or from different 163 vendors to provide a single optical channel interface and transport 164 it over an optical network composed of amplifiers, filters, add-drop 165 multiplexers which may be from a different vendor. Therefore the 166 standard defines the ingress and egress parameters for the optical 167 interfaces at the reference points Ss and Rs. 169 Single Channel DWDM Interface: The single channel interfaces to DWDM 170 systems defined in G.698.2, which currently include the following 171 features: channel frequency spacing: 50 GHz and wider (defined in 172 [ITU-T G.694.1]); bit rate of single channel: Up to 10 Gbit/s. 173 Future revisions are expected to include application codes for bit 174 rates up to 40 Gb/s. 176 Forward error correction (FEC): FEC is a way of improving the 177 performance of high-capacity optical transmission systems. Employing 178 FEC in optical transmission systems yields system designs that can 179 accept relatively large BER (much more than 10-12) in the optical 180 transmission line (before decoding). 182 Administrative domain [G.805]: For the purposes of this 183 Recommendation an administrative domain represents the extent of 184 resources which belong to a single player such as a network operator, 185 a service provider or an end-user. Administrative domains of 186 different players do not overlap amongst themselves. 188 Intra-domain interface (IaDI) [G.872]: A physical interface within an 189 administrative domain. 191 Inter-domain interface (IrDI) [G.872]: A physical interface that 192 represents the boundary between two administrative domains. 194 Management Plane [G.8081]: The management plane performs management 195 functions for the transport plane, the control plane and the system 196 as a whole. It also provides coordination between all the planes. 197 The following management functional areas are performed in the 198 management plane: performance management; fault management; 199 configuration management; accounting management and security 200 management. 202 Control Plane[G.8081]: The control plane performs neighbour 203 discovery, call control and connection control functions. Through 204 signalling, the control plane sets up and releases connections, and 205 may restore a connection in case of a failure. The control plane 206 also performs other functions in support of call and connection 207 control, such as neighbour discovery and routing information 208 dissemination. 210 Transponder: A Transponder is a network element that performs O/E/O 211 (Optical /Electrical/Optical) conversion. In this document it is 212 referred only transponders with 3R (rather than 2R or 1R 213 regeneration) as defined in [ITU.G.872]. 215 Client DWDM interface: A Transceiver element that performs E/O 216 (Electrical/Optical) conversion. In this document it is referred as 217 the DWDM side of a transponder as defined in [ITU.G.872]. 219 3. Solution Space 221 The solution space of this document is focusing on aspects related to 222 the management of single-channel optical interface parameters of 223 physical point-to-point and ring DWDM applications on single-mode 224 optical fibres and allows the direct connection of a wide variety of 225 equipment using a DWDM link, for example 227 1. A digital cross-connect with multiple optical interfaces, 228 supplied by a different vendor from the line system 230 2. Devices as routing, switching or compute nodes, each from a 231 different vendor, supplying one channel each 233 3. A combination of the above 235 3.1. Comparison of approaches for transverse compatibility 237 This section describes two ways to achieve transverse compatibility. 238 Section 3.1.1 describes the classic model based on well defined 239 inter-domain interfaces. Section 3.1.2 defines a model ensuring 240 interoperability on the line side of the optical network. 242 3.1.1. Multivendor DWDM line system with transponders 244 As illustrated in Figure 1, for this approach interoperability is 245 achieved via the use of optical transponders providing OEO (allowing 246 conversion to appropriate parameters). The optical interfaces can 247 then be any short reach standardized optical interface that both 248 vendors support, such as those found in [ITU-T G.957] [ITU-T G.691], 249 [ITU-T G.693], [ITU-T G.959.1], etc. 251 IrDI IaDI 252 | | 253 . . 254 | +----------------------------|----+ 255 . | + WDM Domain + . | 256 | | |\ /| | | 257 +------+ . | | \ |\ / | . | +------+ 258 | TX/ |-->--+---+--T/-|OM|----|/-------|OD|--+-\T-+---->--| RX/ | 259 | RX |--<--+---+--T/-| |----- /|-----| |--.-\T-+----<--| TX | 260 +------+ | | | / \| \ | | | +------+ 261 . | |/ \| . | 262 | | + + | | 263 . +----------------------------.----+ 264 | | 266 TX/RX = Single channel non-DWDM interfaces 267 T/ = Transponder 268 OM = Optical Mux 269 OD = Optical Demux 271 Figure 1: Inter and Intra-Domain Interface Identification 273 In the scenario of Figure 1 the administrative domain is defined by 274 the Interdomain Interface (IrDI). This interface terminates the DWDM 275 domain. The line side is characterized by the IaDI. This interface 276 specifies the internal parameter set of the optical administrative 277 domain. In the case of a client DWDM interface deployment this 278 interface moves into the client device and extends the optical and 279 administrative domain towards the client node. ITU-T G.698.2 for 280 example specifies the parameter set for a certain set of 281 applications. 283 This document elaborates only the IaDI Interface as shown in Figure 1 284 as transversely compatible and multi-vendor interface within one 285 administrative domain controlled by the network operator. 287 3.1.2. Integrated single channel DWDM deployments on the client site 289 In case of a deployment as shown in Figure 2, through the use of 290 single channel DWDM interfaces, multi-vendor interconnection can also 291 be achieved while removing the need for one short reach transmitter 292 and receiver pair per channel (eliminating the transponders). 294 Figure 2 shows a set of reference points, for single-channel 295 connection (Ss and Rs) between transmitters (Tx) and receivers (Rx). 296 Here the DWDM network elements include an optical multiplexer (OM) 297 and an optical demultiplexer (OD) (which are used as a pair with the 298 peer element), one or more optical amplifiers and may also include 299 one or more OADMs. 301 |==================== Black Link =======================| 303 +-------------------------------------------------+ 304 Ss | | DWDM Network Elements | | Rs 305 +---+ | | | \ / | | | +---+ 306 Tx L1---|->| \ +------+ +------+ / |--|-->Rx L1 307 +---+ | | | | | +------+ | | | | | +---+ 308 +---+ | | | | | | | | | | | | +---+ 309 Tx L2---|->| OM |-|>|------|->| OADM |--|------|->| OD |--|-->Rx L2 310 +---+ | | | | | | | | | | | | +---+ 311 +---+ | | | | | +------+ | | | | | +---+ 312 Tx L3---|->| / | DWDM | | ^ | DWDM | \ |--|-->Rx L3 313 +---+ | | / | Link +----|--|----+ Link | \ | | +---+ 314 +-----------+ | | +----------+ 315 +--+ +--+ 316 | | 317 v | 318 +---+ +---+ 319 RxLx TxLx 320 +---+ +---+ 322 Ss = Reference point at the DWDM network element tributary output 323 Rs = Reference point at the DWDM network element tributary input 324 Lx = Lambda x 325 OM = Optical Mux 326 OD = Optical Demux 327 OADM = Optical Add Drop Mux 329 Linear DWDM network as per ITU-T G.698.2 331 Figure 2: Linear Black Link 333 As shown in Figure 2, the administrative domain may consists of 334 several vendor domains. Even a in that case a common north bound 335 management interface is required to ensure a consistent management of 336 the entire connection. 338 The following documents[DWDM-interface-MIB], [YANG], [LMP] define 339 such a protocol- FIX-THE-REFERENCE specific information using SNMP/ 340 SMI, Yang models and LMP TLV to support the direct exchange of 341 information between the client and the network control plane. 343 4. Solutions for managing and controlling single channel optical 344 interface 346 Operation and management of WDM systems is traditionally seen as a 347 homogenous group of tasks that could be carried out best when a 348 single management system or an umbrella management system is used. 349 Currently each WDM vendor provides an Element Management System (EMS) 350 that also administers the wavelengths. 352 Therefore from the operational point of view the following approaches 353 will be considered to manage and operate optical interfaces. 355 1. Separate operation and management of client device and the 356 transport network whereas the single channel interface of the 357 client belongs to the administrative domain of the transport 358 network and will be managed by the transport group. This results 359 in two different approaches to send information to the management 360 system 362 a.Direct connection from the client to the management 363 system,ensuring a management of the single channel of the optical 364 network (e.g. EMS, NMS) 366 b.Indirect connection to the management system of the optical 367 network using a protocol (LMP) between the client device and the 368 directly connected WDM system node to exchange management 369 information with the optical domain 371 2. Common operation and management of client device including the 372 single channel DWDM part and the Transport network 374 The first option keeps the status quo in large carrier networks as 375 mentioned above. In that case it must be ensured that the full FCAPS 376 Management (Fault, Configuration, Accounting, Performance and 377 Security) capabilities are supported. This means from the management 378 staff point of view nothing changes. The transceiver/receiver 379 optical interface will be part of the optical management domain and 380 will be managed from the transport management staff. 382 The second solution addresses the case where underlying WDM transport 383 network is mainly used to interconnect a homogeneous set of client 384 nodes (e.g. IP routers or digital crossconnects). Since the service 385 creation and restoration could be done by the higher layers (e.g. 387 IP), this may lead to an efficient network operation and a higher 388 level of integration. 390 4.1. Separate Operation and Management Approaches 392 4.1.1. Direct connection to the management system 394 As depicted in Figure 3 (case 1a) one possibility to manage the 395 optical interface within the client domain is a direct connection to 396 the management system of the optical domain. This ensures 397 manageability as usual. 399 +-----+ 400 | NMS | 401 |_____| 402 /_____/ 403 | 404 | 405 | 406 +---+---+ 407 +----->+ EMS | 408 / | | 409 / +-------+ 410 / | MI SNMP or Yang 411 SNMP / or Yang | DCN Network 412 --------------------+------------------------------- 413 / +------+-----------------------+ 414 / | +| WDM Domain + | 415 / | |\ /| | 416 +---+--+ | | \ |\ / | | +------+ 417 | CL |-/C------+-----|OM|----|/-------|OD|----+-------/C-| CL | 418 | |-/C------+-----| |----- /|-----| |----+-------/C-| | 419 +------+ | | / \| \ | | +------+ 420 | |/ \| | 421 | + + | 422 +------------------------------+ 424 CL = Client Device 425 /C = Single Channel Optical Interface 426 OM = Optical Mux 427 OD = Optical Demux 428 EMS = Element Management System 429 MI= Management Interface 431 Figure 3: Connecting Single Channel optical interfaces to the 432 Transport Management system 434 The exchange of management information between client device and the 435 management system assumes that some form of a direct management 436 communication link exists between the client device and the DWDM 437 management system (e.g. EMS). This may be an Ethernet Link or a DCN 438 connection (management communication channel MCC). 440 It must be ensured that the optical network interface can be managed 441 in a standardised way to enable interoperable solutions between 442 different optical interface vendors and vendors of the optical 443 network management application. RFC 3591 [RFC3591] defines managed 444 objects for the optical interface type but needs further extension to 445 cover the optical parameters required by this framework document. 446 Therefore an extension to this MIB for the optical interface has been 447 drafted in [DWDM-interface-MIB]. SNMP is used to read parameters and 448 get notifications and alarms, netconf and Yang models are needed to 449 easily provision the interface with the right parameter set as 450 described in [YANG] 452 Note that a software update of the optical interface components of 453 the client nodes must not lead obligatory to an update of the 454 software of the EMS and vice versa. 456 4.1.2. Direct connection to the DWDM management system 457 An alternative as shown in Figure 4 can be used in cases where a more 458 integrated relationship between transport node (e.g. OM or OD) and 459 client device is aspired. In that case a combination of control 460 plane features and manual management will be used. 462 +-----+ 463 | NMS | 464 |_____| 465 /_____/ 466 | 467 | 468 +---+---+ 469 | EMS | 470 | | 471 +-------+ 472 | MI SNMP or Yang 473 | 474 LMP +------+-----------------------+ 475 +------------+---+ +| + | 476 | | | |\ /| | 477 +---+--+ | +-+ \ |\ / | | +------+ 478 | CL |-/C------+--- -|OM|----|/-------|OD|--- +-------/C-| CL | 479 | |-/C------+--- -| |----- /|-----| |----+-------/C-| | 480 +------+ | | / \| \ | | +------+ 481 | |/ \| | 482 | + + | 483 +------------------------------+ 485 CL = Client Device 486 /C = Single Channel optical Interface 487 OM = Optical Mux 488 OD = Optical Demux 489 EMS= Element Management System 490 MI= Management Interface 492 Figure 4: Direct connection between peer node and first optical 493 network node 495 For information exchange between the client node and the direct 496 connected node of the optical transport network LMP as specified in 497 RFC 4209 [RFC4209] should be used. This extension of LMP may be used 498 between a peer node and an adjacent optical network node as depicted 499 in Figure 4. 501 The LMP based on RFC 4209 does not yet support the transmission of 502 configuration data (information). This functionality must be added 503 to the existing extensions of the protocol. The use of LMP-WDM 504 assumes that some form of a control channel exists between the client 505 node and the WDM equipment. This may be a dedicated lambda, an 506 Ethernet Link, or other signalling communication channel (SCC or 507 IPCC). 509 4.2. Control Plane Considerations 511 The concept of integrated single channel DWDM interfaces equally 512 applies to management and control plane mechanisms. The general 513 GMPLS control plane for wavelength switched optical networks is work 514 under definition in the scope of WSON. One important aspect of the 515 BL is the fact that it includes the wavelength that is supported by 516 the given link. Thus a BL can logically be considered as a fiber 517 that is transparent only for a single wavelength. In other words, 518 the wavelength becomes a characteristic of the link itself. 519 Nevertheless the procedure to light up the fiber may vary depending 520 on the implementation. Since the implementation is unknown a priori, 521 different sequences to light up a wavelength need to be considered: 523 1. Interface first, interface tuning: The transmitter is switched on 524 and the link is immediately transparent to its wavelength. This 525 requires the transmitter to carefully tune power and frequency 526 not overload the line system or to create transients. 528 2. Interface first, OLS tuning: The transmitter is switched on first 529 and can immediately go to the max power allowed since the OLS 530 performs the power tuning. This leads to an intermediate state 531 where the receiver does not receive a valid signal while the 532 transmitter is sending out one. Alarm suppression mechanisms 533 shall be employed to overcome that condition. 535 3. OLS first, interface tuning: At first the OLS is tuned to be 536 transparent for a given wavelength, then transponders need to be 537 tuned up. Since the OLS in general requires the presence of a 538 wavelength to fine-tune it is internal facilities there may be a 539 period of time where a valid signal is transmitted but the 540 receiver is unable to detect it. This equally need to be covered 541 by alarm suppression mechanisms. 543 4. OLS first, OLS tuning: The OLS is programmed to be transparent 544 for a given wavelength, then the interfaces need to be switched 545 on and further power tuning takes place. The sequencing of 546 enabling the link needs to be covered as well. 548 The preferred way to address these in a Control Plane enabled network 549 is neighbour discovery including exchange of link characteristics and 550 link property correlation. The general mechanisms are covered in 551 RFC4209 [LMP-WDM] and RFC 4204[LMP] which provides the necessary 552 protocol framework to exchange those characteristics between client 553 and black link. LMP-WDM is not intended for exchanging routing or 554 signaling information but covers: 556 1. Control channel management 558 2. Link property correlation 560 3. Link verification 562 4. Fault management 564 Extensions to LMP/LMP-WDM covering the code points of the BL 565 definition are needed. Additionally when client and server side are 566 managed by different operational entities, link state exchange is 567 required to align the management systems. 569 4.2.1. Considerations using GMPLS UNI 571 The deployment of single channel optical interfaces is leading to 572 some functional changes related to the control plane models and has 573 therefore some impact on the existing interfaces especially in the 574 case of an overlay model where the edge node requests resources from 575 the core node and the edges node do not participate in the routing 576 protocol instance that runs among the core nodes. RFC 4208 [RFC4208] 577 defines the GMPLS UNI that will be used between edge and core node. 578 In case of integrated interfaces deployment additional 579 functionalities are needed to setup a connection. 581 It is necessary to differentiate between topology/signalling 582 information and configuration parameters that are needed to setup a 583 wavelength path. RSVP-TE could be used for the signalling and the 584 reservation of the wavelength path. But there are additional 585 information needed before RSVP-TE can start the signalling process. 586 There are three possibilities to proceed: 588 a. Using RSVP-TE only for the signalling and LMP as described above 589 to exchange information to configure the optical interface within 590 the edge node or 592 b. RSVP-TE will be used to transport additional information 594 c. Leaking IGP information instead of exchanging this information 595 needed from the optical network to the edge node (overlay will be 596 transformed to a border-peer model) 598 Furthermore following issues should be addressed: 600 a) The Communication between peering edge nodes using an out of band 601 control channel. The two nodes have to exchange their optical 602 capabilities. An extended version of LMP is needed to exchange FEC 603 Modulation scheme, etc. that must be the same. It would be helpful 604 to define some common profiles that will be supported. Only if the 605 profiles match with both interface capabilities it is possible start 606 signalling. 608 b) Due to the bidirectional wavelength path that must be setup it is 609 obligatory that the upstream edge node inserts a wavelength value 610 into the path message for the wavelength path towards the upstream 611 node itself. But in the case of an overlay model the client device 612 may not have full information which wavelength must/should be 613 selectedand this information must be exchanged between the edge and 614 the core node. 616 5. Use cases 618 A Comparison with the traditional operation scenarios provides an 619 insight of similarities and distinctions in operation and management 620 of single channel optical interfaces. The following use cases 621 provide an overview about operation and maintenance processes. 623 5.1. Service Setup 625 It is necessary to differentiate between two operational issues for 626 setting up a light path (a DWDM connection is specific in having 627 defined maximum impairments) within an operational network. The 628 first step is the preparation of the connection if no optical signal 629 is applied. Therefore it is necessary to define the path of the 630 connection. 632 The second step is to setup the connection between the client DWDM 633 interface and the ROADM port. This is done using the NMS of the 634 optical transport network. From the operation point of view the task 635 is similar in a Black Link scenario and in a traditional WDM 636 environment. The Black Link connection is measured by using BER 637 tester which use optical interfaces according to G.698.2. These 638 measurements are carried out in accordance with [ITU-TG.692]. When 639 needed further connections for resilience are brought into service in 640 the same way. 642 In addition some other parameters like the transmit optical power, 643 the received optical power, the frequency, etc. must be considered. 645 If the optical interface moves into a client device some of changes 646 from the operational point of view have to be considered. The centre 647 frequency of the Optical Channel was determined by the setup process. 649 The optical interfaces at both terminals are set to the centre 650 frequency before interconnected with the dedicated ports of the WDM 651 network. Optical monitoring is activated in the WDM network after 652 the terminals are interconnected with the dedicated ports in order to 653 monitor the status of the connection. The monitor functions of the 654 optical interfaces at the terminals are also activated in order to 655 monitor the end to end connection. 657 Furthermore it should be possible to automate this last step. After 658 connecting the client device towards the first control plane managed 659 transport node a control connection may e.g. be automatically 660 established using LMP to exchange configuration information. 662 If tunable interfaces are used in the scenario it would be possible 663 to define a series of backup wavelength routes for restoration that 664 could be tested and stored in backup profile. In fault cases this 665 wavelength routes can be used to recover the service. 667 5.2. Link monitoring Use Cases 669 The use cases described below are assuming that power monitoring 670 functions are available in the ingress and egress network element of 671 the DWDM network, respectively. By performing link property 672 correlation it would be beneficial to include the current transmit 673 power value at reference point Ss and the current received power 674 value at reference point Rs. For example if the Client transmitter 675 power (OXC1) has a value of 0dBm and the ROADM interface measured 676 power (at OLS1) is -6dBm the fiber patch cord connecting the two 677 nodes may be pinched or the connectors are dirty. More, the 678 interface characteristics can be used by the OLS network Control 679 Plane in order to check the Optical Channels feasibility. Finally 680 the OXC1 transceivers parameters (Application Code) can be shared 681 with OXC2 using the LMP protocol to verify the transceivers 682 compatibility. The actual route selection of a specific wavelength 683 within the allowed set is outside the scope of LMP. In GMPLS, the 684 parameter selection (e.g. central frequency) is performed by RSVP-TE. 686 G.698.2 defines a single channel optical interface for DWDM systems 687 that allows interconnecting network-external optical transponders 688 across a DWDM network. The optical transponders are considered to be 689 external to the DWDM network. This so-called 'black link' approach 690 illustrated in Figure 5-1 of G.698.2 and a copy of this figure is 691 provided below. The single channel fiber link between the Ss/Rs 692 reference points and the ingress/egress port of the network element 693 on the domain boundary of the DWDM network (DWDM border NE) is called 694 access link in this contribution. Based on the definition in G.698.2 695 it is considered to be part of the DWDM network. The access link 696 typically is realized as a passive fiber link that has a specific 697 optical attenuation (insertion loss). As the access link is an 698 integral part of the DWDM network, it is desirable to monitor its 699 attenuation. Therefore, it is useful to detect an increase of the 700 access link attenuation, for example, when the access link fiber has 701 been disconnected and reconnected (maintenance) and a bad patch panel 702 connection (connector) resulted in a significantly higher access link 703 attenuation (loss of signal in the extreme case of an open connector 704 or a fiber cut). In the following section, two use cases are 705 presented and discussed: 707 1) pure access link monitoring 708 2) access link monitoring with a power control loop 710 These use cases require a power monitor as described in G.697 (see 711 section 6.1.2), that is capable to measure the optical power of the 712 incoming or outgoing single channel signal. The use case where a 713 power control loop is in place could even be used to compensate an 714 increased attenuation as long as the optical transmitter can still be 715 operated within its output power range defined by its application 716 code. 718 Figure 5 Access Link Power Monitoring 720 +--------------------------+ 721 | P(in) = P(Tx) - a(Tx) | 722 | ___ | 723 +----------+ | \ / Power Monitor | 724 | | P(Tx) | V P(in) | 725 | +----+ | Ss //\\ | | |\ | 726 | | TX |----|-----\\//------------------->| \ | 727 | +----+ | Access Link (AL-T) | . | | | 728 | | attenuation a(Tx) | . | |==============> 729 | | | . | | | 730 | External | | --->| / | 731 | Optical | | |/ | 732 |Transpond.| | P(out) | 733 | | | ___ | 734 | | | \ / Power Monitor | 735 | | P(Rx) | V P(out) | 736 | +----+ | Rs //\\ | | |\ | 737 | | RX |<---|-----\\//--------------------| \ | 738 | +----+ | Access Link (AL-R) | . | | | 739 | | Attenuation a(Rx) | . | |<============== 740 +----------+ | . | | | 741 | <---| / | 742 P(Rx) = P(out) - a(Rx) | |/ | 743 | | 744 | ROADM | 745 +--------------------------+ 747 - For AL-T monitoring: P(Tx) and a(Tx) must be known 748 - For AL-R monitoring: P(RX) and a(Rx) must be known 750 An alarm shall be raised if P(in) or P(Rx) drops below a 751 configured threshold (t [dB]): 752 - P(in) < P(Tx) - a(Tx) - t (Tx direction) 753 - P(Rx) < P(out) - a(Rx) - t (Rx direction) 754 - a(Tx) =| a(Rx) 756 Figure 5: Extended LMP Model 758 5.2.1. Pure Access Link (AL) Monitoring Use Case 759 Figure 6 illustrates the access link monitoring use case and the 760 different physical properties involved that are defined below: 762 - Ss, Rs: Single Channel reference points 763 - P(Tx): current optical output power of transmitter Tx 764 - a(Tx): access link attenuation in Tx direction (external 765 transponder point of view) 766 - P(in): measured current optical input power at the input port 767 of border DWDM NE 768 - t: user defined threshold (tolerance) 769 - P(out): measured current optical output power at the output port 770 of border DWDM NE 771 - a(Rx): access link attenuation in Rx direction (external 772 transponder point of view) 773 - P(Rx): current optical input power of receiver Rx 775 Description: 776 - The access link attenuation in both directions (a(Tx), a(Rx)) 777 is known or can be determined as part of the commissioning 778 process. Typically, both values are the same. 779 - A threshold value t has been configured by the operator. This 780 should also be done during commissioning. 781 - A control plane protocol (e.g. this draft) is in place that allows 782 to periodically send the optical power values P(Tx) and P(Rx) 783 to the control plane protocol instance on the DWDM border NE. 784 This is illustrated in Figure 3. 785 - The DWDM border NE is capable to periodically measure the optical 786 power Pin and Pout as defined in G.697 by power monitoring points 787 depicted as yellow triangles in the figures below. 789 Access Link monitoring process: 790 - Tx direction: the measured optical input power Pin is compared 791 with the expected optical input power P(Tx) - a(Tx). If the 792 measured optical input power P(in) drops below the value 793 (P(Tx) - a(Tx) - t) a low power alarm shall be raised indicating 794 that the access link attenuation has exceeded a(Tx) + t. 795 - Rx direction: the measured optical input power P(Rx) is 796 compared with the expected optical input power P(out) - a(Rx). 797 If the measured optical input power P(Rx) drops below the value 798 (P(out) - a(Rx) - t) a 799 low power alarm shall be raised indicating that the access link 800 attenuation has exceeded a(Rx) + t. 801 - to avoid toggling errors, the low power alarm threshold shall be 802 lower than the alarm clear threshold. 804 Figure 6 Use case 1: Access Link monitoring 806 +----------+ +--------------------------+ 807 | +------+ | P(Tx), P(Rx) | +-------+ | 808 | | | | =================> | | | | 809 | | LMP | | P(in), P(out) | | LMP | | 810 | | | | <================= | | | | 811 | +------+ | | +-------+ | 812 | | | | 813 | | | P(in) - P(Tx) - a(Tx) | 814 | | | ___ | 815 | | | \ / Power Monitor | 816 | | P(Tx) | V | 817 | +----+ | Ss //\\ | | |\ | 818 | | TX |----|-----\\//------------------->| \ | 819 | +----+ | Access Link (AL-T) | . | | | 820 | | attenuation a(Tx) | . | |==============> 821 | | | . | | | 822 | External | | --->| / | 823 | Optical | | |/ | 824 |Transpond.| | P(out) | 825 | | | ___ | 826 | | | \ / Power Monitor | 827 | | P(Rx) | V | 828 | +----+ | Rs //\\ | | |\ | 829 | | RX |<---|-----\\//--------------------| \ | 830 | +----+ | Access Link (AL-R) | . | | | 831 | | Attenuation a(Rx) | . | |<============== 832 +----------+ | . | | | 833 | <---| / | 834 P(Rx) = P(out) - a(Rx) | |/ | 835 | | 836 | ROADM | 837 +--------------------------+ 839 - For AL-T monitoring: P(Tx) and a(Tx) must be known 840 - For AL-R monitoring: P(RX) and a(Rx) must be known 841 An alarm shall be raised if P(in) or P(Rx) drops below a 842 configured threshold (t [dB]): 843 - P(in) < P(Tx) - a(Tx) - t (Tx direction) 844 - P(Rx) < P(out) - a(Rx) - t (Rx direction) 845 - a(Tx) = a(Rx) 847 Figure 6: Extended LMP Model 849 5.2.2. Power Control Loop Use Case 851 This use case is based on the access link monitoring use case as 852 described above. In addition, the border NE is running a power 853 control application that is capable to control the optical output 854 power of the single channel tributary signal at the output port 855 of the border DWDM NE (towards the external receiver Rx) and the 856 optical output power of the single channel tributary signal at 857 the external transmitter Tx within their known operating range. 858 The time scale of this control loop is typically relatively slow 859 (e.g. some 10s or minutes) because the access link attenuation 860 is not expected to vary much over time (the attenuation only 861 changes when re-cabling occurs). 862 From a data plane perspective, this use case does not require 863 additional data plane extensions. It does only require a protocol 864 extension in the control plane (e.g. this LMP draft) that allows 865 the power control application residing in the DWDM border NE to 866 modify the optical output power of the DWDM domain-external 867 transmitter Tx within the range of the currently used application 868 code. Figure 5 below illustrates this use case utilizing the LMP 869 protocol with extensions defined in this draft. 871 Figure 7 Use case 2: Power Control Loop 873 +----------+ +--------------------------+ 874 | +------+ | P(Tx),P(Rx),Set(Pout) | +-------+ +--------+ | 875 | | | | ====================> | | | | Power | | 876 | | LMP | | P(in),P(out),Set(PTx) | | LMP | |Control | | 877 | | | | <==================== | | | | Loop | | 878 | +------+ | | +-------+ +--------+ | 879 | | | | | 880 | +------+ | | P(in) = P(Tx) - a(Tx) | 881 | |C.Loop| | | ___ | 882 | +------+ | | \ / Power Monitor | 883 | | | P(Tx) | V | 884 | +------+ | Ss //\\ | | |\ | 885 | | TX |>----|-----\\//---------------------->| \ | 886 | +------+ | Access Link (AL-T) | . | | | 887 | VOA(Tx) | attenuation a(Tx) | . | |==============> 888 | | | . | | | 889 | External | | --->| / | 890 | Optical | | |/ | 891 |Transpond.| | P(out) | 892 | | | ___ | 893 | | | \ / Power Monitor | 894 | | P(Rx) | V | 895 | +----+ | Rs //\\ | | VOA(out) |\ | 896 | | RX |<---|-----\\//---------------------<|-------| \ | 897 | +----+ | Access Link (AL-R) | . | | | 898 | | attenuation a(Rx) | . | |<======= 899 +----------+ | VOA(out) | | | 900 | <--<|-------| / | 901 P(Rx) = P(out) - a(Rx) | |/ | 902 | | 903 | ROADM | 904 +--------------------------+ 906 Figure 7: Power control loop 908 - The Power Control Loops in Transponder and ROADM controls 909 the Variable Optical Attenuators (VOA) to adjust the proper 910 power in base of the ROADM and Receiver caracteristics and 911 the Access Link attenuation 913 6. Requirements 915 Even if network architectures becomes more complex the management and 916 operation as well as the provisioning process should have a higher 917 degree of automation or should be fully automated. Simplifying and 918 automating the entire management and provisioning process of the 919 network in combination with a higher link utilization and faster 920 restoration times will be the major requirements that has been 921 addressed in this section. 923 Data Plane interoperability as defined for example in [ITU.G698.2] is 924 a precondition to ensure plain solutions and allow the usage of 925 standardized interfaces between network and control/management plane. 927 The following requirements are focusing on the usage of integrated 928 single channel interfaces. 930 1 To ensure a lean management and provisioning process of single 931 channel interfaces management and control plane of the client 932 and DWDM network must be aware of the parameters of the 933 interfaces and the optical network to properly setup the optical 934 connection. 936 2 A standard-based northbound API (to network management system) 937 based on Netconf should be supported, alternatively SNMP should 938 be supported too. 940 3 A standard-based data model for single channel interfaces must be 941 supported to exchange optical parameters with control/management 942 plane. 944 4 Netconf should be used also for configuration of the single 945 channel interfaces including the power setting 947 5 LMP should be extended and used in cases where optical 948 parameters need to be exchanged between peer nodes to correlate 949 link characteristics and adopt the working mode of the single 950 channel interface. 952 6 LMP may be used to adjust the output power of the single 953 channel DWDM interface to ensure that the interface works in 954 the right range. 956 7 Parameters e.g. PRE-FEC BER should be used to trigger a FRR 957 mechanism on the IP control plane to reroute traffic before 958 the link breaks. 960 8 Power monitoring functions at both ends of the DWDM connection 961 should be implemented to further automate the setup and 962 shoutdown process of the optical interfaces. 964 9 A standardized procedure to setup an optical connection should 965 be defined and implemented in DWDM and client devices 966 (containing the single channel optical interface).LMP should be 967 used to ensure that the process follows the right order. 969 10 Pre-tested and configured backup paths should be stored in so 970 called backup profiles. In fault cases this wavelength routes 971 should be used to recover the service. 973 11 LMP may be used to monitor and observe the access link. 975 7. Acknowledgements 977 The authors would like to thank all who supported the work with 978 fruitful discussions and contributions. 980 8. IANA Considerations 982 This memo includes no request to IANA. 984 9. Security Considerations 986 The architecture and solution space in scope of this framework 987 imposes no additional requirements to the security models already 988 defined in RFC5920 for packet/optical networks using GMPLS, covering 989 also Control Plane and Management interfaces. Respective security 990 mechanisms of the components and protocols, e.g. LMP security 991 models, can be applied unchanged. 993 As this framework is focusing on the single operator use case, the 994 security concerns can be relaxed to a subset compared to a setup 995 where information is exchanged between external parties and over 996 external interfaces. 998 Concerning the access control to Management interfaces, security 999 issues can be generally addressed by authentication techniques 1000 providing origin verification, integrity and confidentiality. 1001 Additionally, access to Management interfaces can be physically or 1002 logically isolated, by configuring them to be only accessible out-of- 1003 band, through a system that is physically or logically separated from 1004 the rest of the network infrastructure. In case where management 1005 interfaces are accessible in-band at the client device or within the 1006 optical transport netork domain, filtering or firewalling techniques 1007 can be used to restrict unauthorized in-band traffic. Authentication 1008 techniques may be additionally used in all cases. 1010 10. Contributors 1011 Arnold Mattheus 1012 Deutsche Telekom 1013 Darmstadt 1014 Germany 1015 email arnold.Mattheus@telekom.de 1017 Manuel Paul 1018 Deutsche Telekom 1019 Berlin 1020 Germany 1021 email Manuel.Paul@telekom.de 1023 Josef Roese 1024 Deutsche Telekom 1025 Darmstadt 1026 Germany 1027 email j.roese@telekom.de 1029 Frank Luennemann 1030 Deutsche Telekom 1031 Muenster 1032 Germany 1033 email Frank.Luennemann@telekom.de 1035 11. References 1037 11.1. Normative References 1039 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group 1040 MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000, 1041 . 1043 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1044 Requirement Levels", BCP 14, RFC 2119, 1045 DOI 10.17487/RFC2119, March 1997, 1046 . 1048 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 1049 Schoenwaelder, Ed., "Structure of Management Information 1050 Version 2 (SMIv2)", STD 58, RFC 2578, 1051 DOI 10.17487/RFC2578, April 1999, 1052 . 1054 [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. 1055 Schoenwaelder, Ed., "Textual Conventions for SMIv2", 1056 STD 58, RFC 2579, DOI 10.17487/RFC2579, April 1999, 1057 . 1059 [RFC2580] McCloghrie, K., Ed., Perkins, D., Ed., and J. 1060 Schoenwaelder, Ed., "Conformance Statements for SMIv2", 1061 STD 58, RFC 2580, DOI 10.17487/RFC2580, April 1999, 1062 . 1064 [RFC3591] Lam, H-K., Stewart, M., and A. Huynh, "Definitions of 1065 Managed Objects for the Optical Interface Type", RFC 3591, 1066 DOI 10.17487/RFC3591, September 2003, 1067 . 1069 [RFC6205] Otani, T., Ed. and D. Li, Ed., "Generalized Labels for 1070 Lambda-Switch-Capable (LSC) Label Switching Routers", 1071 RFC 6205, DOI 10.17487/RFC6205, March 2011, 1072 . 1074 [RFC4209] Fredette, A., Ed. and J. Lang, Ed., "Link Management 1075 Protocol (LMP) for Dense Wavelength Division Multiplexing 1076 (DWDM) Optical Line Systems", RFC 4209, 1077 DOI 10.17487/RFC4209, October 2005, 1078 . 1080 [ITU.G698.2] 1081 International Telecommunications Union, "Amplified 1082 multichannel dense wavelength division multiplexing 1083 applications with single channel optical interfaces", 1084 ITU-T Recommendation G.698.2, November 2009. 1086 [ITU.G709] 1087 International Telecommunications Union, "Interface for the 1088 Optical Transport Network (OTN)", ITU-T Recommendation 1089 G.709, March 2003. 1091 [ITU.G.872] 1092 International Telecommunications Union, "Architecture of 1093 optical transport networks", ITU-T Recommendation G.872, 1094 November 2001. 1096 11.2. Informative References 1098 [DWDM-interface-MIB] 1099 Internet Engineering Task Force, "A SNMP MIB to manage the 1100 DWDM optical interface parameters of DWDM applications", 1101 draft-galimkunze-ccamp-dwdm-if-snmp-mib draft-galimkunze- 1102 ccamp-dwdm-if-snmp-mib, July 2011. 1104 [ITU-TG.691] 1105 ITU-T, "Optical interfaces for single channel STM-64 and 1106 other SDH systems with optical amplifiers", 1107 ITU-T Recommendation ITU-T G.691, 2008. 1109 [ITU-TG.693] 1110 ITU-T, "Optical interfaces for intra-office systems", 1111 ITU-T Recommendation ITU-T G.693, 2009. 1113 [ITU-TG.957] 1114 ITU-T, "Optical interfaces for equipments and systems 1115 relating to the synchronous digital hierarchy", 1116 ITU-T Recommendation ITU-T G.957, 2006. 1118 [ITU-TG.692] 1119 ITU-T, "Transmission media characteristics - 1120 Characteristics of optical components and sub-systems", 1121 ITU-T Recommendation ITU-T G.692, 1998. 1123 [ITU-TG.959.1] 1124 ITU-T, "Optical transport network physical layer 1125 interfaces", ITU-T Recommendation ITU-T G.959.1, 2009. 1127 [ITU-TG.8081] 1128 ITU-T, "Terms and definitions for Automatically Switched 1129 Optical Networks (ASON)", ITU-T Recommendation G.8081", 1130 ITU-T Recommendation ITU-T G.8081, September 2010. 1132 Authors' Addresses 1134 Ruediger Kunze (editor) 1135 Deutsche Telekom 1136 Winterfeldtstr. 21-27 1137 10781 Berlin 1138 Germany 1140 Phone: +491702275321 1141 Email: RKunze@telekom.de 1143 Gert Grammel (editor) 1144 Juniper 1145 Oskar-Schlemmer Str. 15 1146 80807 Muenchen 1147 Germany 1149 Phone: +49 1725186386 1150 Email: ggrammel@juniper.net 1151 Dieter Beller 1152 Nokia 1153 Lorenzstrasse, 10 1154 70435 Stuttgart 1155 Germany 1157 Phone: +4971182143125 1158 Email: Dieter.Beller@nokia.com 1160 Gabriele Galimberti (editor) 1161 Cisco 1162 Via S. Maria Molgora, 48 1163 20871 - Vimercate 1164 Italy 1166 Phone: +390392091462 1167 Email: ggalimbe@cisco.com