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