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