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