idnits 2.17.1 draft-kunze-g-698-2-management-control-framework-02.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([ITUG.698.2]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 9, 2012) is 4431 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'ITU-T G.694.1' is mentioned on line 174, but not defined == Missing Reference: 'G.805' is mentioned on line 188, but not defined == Missing Reference: 'G.872' is mentioned on line 197, but not defined == Missing Reference: 'G.8081' is mentioned on line 208, but not defined == Missing Reference: 'LMP-WDM' is mentioned on line 660, but not defined == Missing Reference: 'LMP' is mentioned on line 660, but not defined == Missing Reference: 'RFC4208' is mentioned on line 685, but not defined == Unused Reference: 'ITU.G709' is defined on line 851, but no explicit reference was found in the text == Unused Reference: 'RFC4204' is defined on line 862, but no explicit reference was found in the text == Unused Reference: 'ITU-T G.8081' is defined on line 886, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 12 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 AG 4 Intended status: Informational G.Grammel, Ed. 5 Expires: September 10, 2012 Juniper Networks 6 GMG. G.Galimberti, Ed. 7 Cisco 8 H.Schmidtke, Ed. 9 Juniper Networks 10 March 9, 2012 12 A framework for Management and Control of G.698.2 optical interface 13 parameters 14 draft-kunze-g-698-2-management-control-framework-02 16 Abstract 18 This document provides a framework that describes a solution space 19 for the control and management of optical interfaces parameters 20 according to the Black Link approach as specified by ITU-T [ITU 21 G.698.2]. In particular, it examines topological elements and 22 related network management processes to operate this construct. This 23 framework is scoped to address the Optical Channel (OCh)-layer 24 covered by G.698.2. The focus is on enabling the wavelength 25 provisioning process in a black link approach irrespective on how it 26 is triggered i.e. by EMS, NMS or GMPLS. This document covers 27 management as well as control plane considerations in different 28 management cases of a single channel DWDM interface as defined by 29 ITU-G.698.2. The purpose is to identify the necessary information 30 elements and processes to be used by control or management devices 31 for further processing. Hence wavelength routing and selection 32 processes as defined e.g. in WSON are beyond the scope of this 33 document. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on September 10, 2012. 51 Copyright Notice 53 Copyright (c) 2012 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 70 2. Terminology and Definitions . . . . . . . . . . . . . . . . . 5 71 3. Solution Space for optical interfaces using a DWDM Black 72 Link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 73 3.1. Comparison of approaches for transverse compatibility . . 7 74 3.1.1. Multivendor DWDM line system with transponders . . . . 7 75 3.1.2. Black Link Deployments . . . . . . . . . . . . . . . . 9 76 4. Operational aspects using IUT-T G.698.2 specified single 77 channel DWDM interfaces . . . . . . . . . . . . . . . . . . . 10 78 4.1. Bringing into service . . . . . . . . . . . . . . . . . . 10 79 4.2. Configuration Management . . . . . . . . . . . . . . . . . 11 80 4.3. In service (performance management) . . . . . . . . . . . 11 81 4.4. Fault Clearance . . . . . . . . . . . . . . . . . . . . . 11 82 5. Solutions for managing and controlling the optical 83 interface within Black Link scenarios . . . . . . . . . . . . 11 84 5.1. BL Separate Operation and Management Approaches . . . . . 12 85 5.1.1. Direct connection to the management system . . . . . . 13 86 5.1.2. Indirect connection to the DWDM management system . . 15 87 5.2. Control Plane Considerations . . . . . . . . . . . . . . . 16 88 5.2.1. Considerations using GMPLS UNI . . . . . . . . . . . . 17 89 6. Requirements for BL deployments . . . . . . . . . . . . . . . 18 90 6.1. Interoperability Aspects . . . . . . . . . . . . . . . . . 18 91 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 92 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 93 9. Security Considerations . . . . . . . . . . . . . . . . . . . 20 94 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 20 95 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 96 11.1. Normative References . . . . . . . . . . . . . . . . . . . 21 97 11.2. Informative References . . . . . . . . . . . . . . . . . . 22 99 1. Introduction 101 The usage of the Black Link approach in carrier applications (which 102 include optical amplifiers) adds further networking option for 103 operators enabling integration of G.698.2 optical interfaces into 104 routers and other types of client devices. 106 Carriers deploy their networks today as a combination of transport 107 and packet infrastructures to ensure high availability and flexible 108 data transport. Both network technologies are usually managed by 109 different operational units using different management concepts. 110 This is the status quo in many carrier networks today. In the case 111 of a black link deployment, where the optical transport interface 112 moves into the client device (e.g. , router), it is necessary to 113 coordinate the management of the optical interface at the client 114 domain with the optical transport domain. There are different levels 115 of coordination, which are specified in this framework. 117 The objective of this document is to provide a framework that 118 describes the solution space for the control and management of single 119 channel interfaces as specified by the ITU-T Recommendation G.698.2 120 [ITU G.698.2]. In particular, it examines topological elements and 121 related network management measures. From an architectural point of 122 view, the black link is a set of pre-configured/qualified 123 unidirectional, single-fiber, network connections between the G.698.2 124 reference points S and R. The optical transport network is managed 125 and controlled in order to provide black links of the intended centre 126 frequencies and the optical interfaces are managed and controlled to 127 generate signals of the intended centre frequencies and further 128 parameters as specified in ITU-T Recommendations G.698.2 and G.798. 130 Optical Routing and Wavelength assignment based on WSON is out of 131 scope. 133 Furthermore, support for Fast Fault Detection, to e.g., trigger ODUk 134 Protection Switching is out of scope of this work. Additionally, the 135 wavelength ordering process and the process how to determine the 136 demand for a new wavelength from A to Z is out of scope. 138 Note that the Control and Management Planes are two separate entities 139 that are handling the same information in different ways. This 140 document covers management as well as control plane considerations in 141 different management cases of single channel DWDM interfaces. 143 1.1. Requirements Language 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 147 document are to be interpreted as described in RFC 2119 [RFC2119]. 149 2. Terminology and Definitions 151 Current generation WDM netwoks are single vendor networks where the 152 optical line system and the transponders are tightly integrated. The 153 Black Link approach changes this situation by introducing a 154 standardized interface at the level of OCh between the line system 155 and transponders. 157 Black Link: The Black Link [ITU G.698.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. In that case the 164 optical connection between the two G.968.2 optical interfaces is 165 referred to as a Black Link. G.698.2 provides an optical interface 166 specification ensuring the realization of transversely compatible 167 dense wavelength division multiplexing (DWDM) systems primarily 168 intended for metro applications which include optical amplifiers and 169 leads towards a multivendor DWDM optical transmission network. 171 Single Channel DWDM Interface: The single channel interfaces to DWDM 172 systems defined in G.698.2, which currently include the following 173 features: channel frequency spacing: 50 GHz and wider (defined in 174 [ITU-T G.694.1]); bit rate of single channel: Up to 10 Gbit/s. 175 Future revisions are expected to include application codes for bit 176 rates up to 40 Gb/s. Single channel DWDM interfaces to/from other 177 vendor(s): G.698.2 provides transverse compatibility at the single- 178 channel point, using a direct wavelength-multiplexing configuration, 179 for single channel DWDM interfaces to/from other vendors (but not at 180 the multi-channel point). 182 Forward error correction (FEC): FEC is a way of improving the 183 performance of high-capacity optical transmission systems. Employing 184 FEC in optical transmission systems yields system designs that can 185 accept relatively large BER (much more than 10-12) in the optical 186 transmission line (before decoding). 188 Administrative domain [G.805]: For the purposes of this 189 Recommendation an administrative domain represents the extent of 190 resources which belong to a single player such as a network operator, 191 a service provider or an end-user. Administrative domains of 192 different players do not overlap amongst themselves. 194 Intra-domain interface (IaDI) [G.872]: A physical interface within an 195 administrative domain. 197 Inter-domain interface (IrDI) [G.872]: A physical interface that 198 represents the boundary between two administrative domains. 200 Management Plane [G.8081]: The management plane performs management 201 functions for the transport plane, the control plane and the system 202 as a whole. It also provides coordination between all the planes. 203 The following management functional areas are performed in the 204 management plane: performance management; fault management; 205 configuration management; accounting management and security 206 management. 208 Control Plane[G.8081]: The control plane performs neighbour 209 discovery, call control and connection control functions. Through 210 signalling, the control plane sets up and releases connections, and 211 may restore a connection in case of a failure. The control plane 212 also performs other functions in support of call and connection 213 control, such as neighbour discovery and routing information 214 dissemination. 216 Transponder: A Transponder is a network element that performs O/E/O 217 (Optical /Electrical/Optical) conversion. In this document it is 218 referred only transponders with 3R (rather than 2R or 1R 219 regeneration) as defined in [ITU.G.872]. 221 3. Solution Space for optical interfaces using a DWDM Black Link 223 The management of optical interfaces using the Black Link approach 224 deals with aspects related to the management of single-channel 225 optical interface parameters of physical point-to-point and ring DWDM 226 applications on single-mode optical fibres. 228 The Black Link approach allows the direct connection of a wide 229 variety of equipments using a DWDM link, for example: 231 a. A digital cross-connect with multiple optical interfaces, 232 supplied by a different vendor from the line system 234 b. Multiple optical client devices, each from a different vendor, 235 supplying one channel each 237 c. A combination of the above 239 Table 1 provides a list of BL management tasks regarding the 240 configuration of optical parameters. 242 +---------------------------------------+---------+----+----+---+---+ 243 | Task | Domain | a | b | c | d | 244 +---------------------------------------+---------+----+----+---+---+ 245 | determination of centre frequency | optical | R | R | R | R | 246 | configuration of centre frequency at | client | NR | NR | R | R | 247 | optical IF | | | | | | 248 | path computation of wavelength | optical | NR | NR | R | R | 249 | routing of wavelength | optical | NR | NR | R | R | 250 | wavelength setup across optical | optical | ? | ? | R | R | 251 | network | | | | | | 252 | detection of wavelength fault | client | R | R | R | R | 253 | fault isolation, identification of | optical | NR | R | R | R | 254 | root failure | | | | | | 255 | repair actions within optical network | optical | R | R | R | R | 256 | protection switching of wavelength | optical | NR | NR | R | R | 257 | restoration of wavelength | optical | NR | NR | R | R | 258 +---------------------------------------+---------+----+----+---+---+ 260 Note: R = relevant, NR = not relevant 262 Table 1: List of tasks related to BL management 264 Furthermore the following deployment cases will be considered: 266 a. Passive WDM 268 b. P2P WDM systems 270 c. WDM systems with OADMs 272 d. Transparent optical networks supporting specific IPoWDM 273 functions, interfaces, protocols etc. 275 Case a) is added for illustration only, since passive WDM is 276 specified in ITU-T Recommendations G.695 and G.698.1. 278 Case b) and case c)are motivated by the usage of legacy equipment 279 using the traditional connection as described in Figure 1combined 280 with the BL approach. 282 3.1. Comparison of approaches for transverse compatibility 284 3.1.1. Multivendor DWDM line system with transponders 286 As illustrated in Figure 1, for this approach interoperability is 287 achieved via the use of optical transponders providing OEO (allowing 288 conversion to appropriate parameters). The optical interfaces 289 labelled "single channel non-DWDM interfaces from other vendor(s)" 290 and "Single channel non DWDM interfaces to/from other vendor(s)" can 291 then be any short reach standardized optical interface that both 292 vendors support, such as those found in [ITU-T G.957] [ITU-T G.691], 293 [ITU-T G.693], [ITU-T G.959.1], etc. 295 IrDI IaDI 296 | | 297 . . 298 | +----------------------------|---+ 299 . | + WDM Domain + . | 300 | | |\ /| | | 301 +------+ . | | \ |\ / | . | +------+ 302 | TX/ |-->--+---+--T/-|OM|----|/-------|OD|--+-\T+------->--| RX/ | 303 | RX |--<--+---+--T/-| |----- /|-----| |--.-\T+-------<--| TX | 304 +------+ | | | / \| \ | | | +------+ 305 . | |/ \| . | 306 | | + + | | 307 . +----------------------------.---+ 308 | | 310 TX/RX = Single channel non-DWDM interfaces 311 T/ = Transponder 312 OM = Optical Mux 313 OD = Optical Demux 315 Figure 1: Inter and Intra-Domain Interface Identification 317 In the scenario of Figure 1 the administrative domain is defined by 318 the Interdomain Interface (IrDI). This interface terminates the DWDM 319 domain. The line side is characterized by the IaDI. This interface 320 specifies the internal parameter set of the optical administrative 321 domain. In the case of black link deployment this interface moves 322 into the client devices and extends the optical and administrative 323 domain towards the client node. ITU-T G.698.2 specifies the 324 parameter set for a certain set of applications. 326 This document elaborates only the IaDI Interface as specified in 327 ITU-T G.698.2 as transversely compatible and multi-vendor interface 328 within one administrative domain controlled by the network operator. 329 This administrative domain can contain several vendor domains (vendor 330 A for the DWDM sub-network, and vendors B1 and B2 at the transmitter 331 and receiver terminal side). 333 3.1.2. Black Link Deployments 335 In case of a Black Link deployment as shown in Figure 2, through the 336 use of the single channel DWDM interfaces defined in [ITU G.698.2], 337 multi-vendor interconnection can also be achieved while removing the 338 need for one short reach transmitter and receiver pair per channel 339 (eliminating the transponders). 341 Figure 2 shows a set of reference points, for the linear "black-link" 342 approach, for single-channel connection (Ss and Rs) between 343 transmitters (Tx) and receivers (Rx). Here the DWDM network elements 344 include an optical multiplexer (OM) and an optical demultiplexer (OD) 345 (which are used as a pair with the peer element), one or more optical 346 amplifiers and may also include one or more OADMs. 348 |==================== Black Link =======================| 350 +-------------------------------------------------+ 351 Ss | DWDM Network Elements | Rs 352 +---+ | | | \ / | | | +---+ 353 Tx L1----|->| \ +------+ +------+ / |--|--->Rx L1 354 +---+ | | | | | +------+ | | | | | +---+ 355 +---+ | | | | | | | | | | | | +---+ 356 Tx L2----|->| OM |-|>|------|->| OADM |--|------|->| OD |--|--->Rx L2 357 +---+ | | | | | | | | | | | | +---+ 358 +---+ | | | | | +------+ | | | | | +---+ 359 Tx L3----|->| / | DWDM | | ^ | DWDM | \ |--|--->Rx L3 360 +---+ | | / | Link +----|--|----+ Link | \ | | +---+ 361 +-----------+ | | +----------+ 362 +--+ +--+ 363 | | 364 v | 365 +---+ +---+ 366 RxLx TxLx 367 +---+ +---+ 368 Ss = Reference point at the DWDM network element tributary output 369 Rs = Reference point at the DWDM network element tributary input 370 Lx = Lambda x 371 OM = Optical Mux 372 OD = Optical Demux 373 OADM = Optical Add Drop Mux 375 Linear black link as per ITU-T G.698.2 377 Figure 2: Linear Black Link 379 In Figure 2, if the administrative domain consists of several domains 380 (e.g. A for a DWDM network supporting the Black Link, B1 for the 381 DWDM Tx, and B2 for the DWDM Rx), it is typical that there will be a 382 separate Element Management Systems (EMS) will be used for each 383 vendor domain (e.g. EMS-a for domain A, EMS-b1 for domain B1, and 384 EMS-b2 for domain B2). Each EMS may have a common standard north 385 bound management interface to a Network Management System (NMS), 386 allowing consistent end-to-end management of the connection. 388 To facilitate consistent end-to-end network management, the north 389 bound management interface from the EMS to the NMS should be 390 consistent (frome a management information point of view) with the 391 standard protocol-neutral (or protocol-specific) information model 392 used in the EMS south bound management interface to its subtending 393 NEs (TX and/or RX). The [Black-Link-MIB] defines such a protocol- 394 specific information using SNMP/SMI. 396 4. Operational aspects using IUT-T G.698.2 specified single channel 397 DWDM interfaces 399 A Comparison of the Black Link with the traditional operation 400 scenarios provides an insight of similarities and distinctions in 401 operation and management. The following four use cases provide an 402 overview about operation and maintenance processes. 404 4.1. Bringing into service 406 It is necessary to differentiate between two operational issues for 407 setting up a light path (a Black Link connection is specific in 408 having defined maximum impairments) within an operational network. 409 The first step is the preparation of the connection if no optical 410 signal is applied. Therefore it is necessary to define the path of 411 the connection. 413 The second step is to setup the Black Link connection. This is done 414 using the NMS of the optical transport network. From the operation 415 point of view the task is similar in a Black Link scenario and in a 416 traditional WDM environment. The Black Link connection is measured 417 by using BER tester which use optical interfaces according to 418 G.698.2. These measurements are carried out in accordance with ITU-T 419 Recommendation M.xxxx. When needed further Black Link connections 420 for resilience are brought into service in the same way. 422 If the optical interface moves into a client device some of changes 423 from the operational point of view have to be considered. The centre 424 frequency of the Black Link connections was determined by the setup 425 process. The optical interfaces at both terminals are set to the 426 centre frequency of the Black Link connection before interconnected 427 with the dedicated ports of the WDM network. Optical monitoring is 428 activated in the WDM network after the terminals are interconnected 429 with the dedicated ports in order to monitor the status of the Black 430 Link connection. The monitor functions of the optical interfaces at 431 the terminals are also activated in order to monitor the end to end 432 connection. 434 Furthermore it should be possible to automate this last step. After 435 connecting the client device towards the first control plane managed 436 transport node a control connection may e.g. be automatically 437 established using LMP to exchange configuration information. 439 If tunable interfaces are used in the Black Link scenario it would be 440 possible to define a series of backup wavelength routes for 441 restoration that could be tested and stored in backup profile. In 442 fault cases this wavelength routes can be used to recover the 443 service. 445 4.2. Configuration Management 447 tbd. 449 4.3. In service (performance management) 451 tbd. 453 4.4. Fault Clearance 455 tbd. 457 5. Solutions for managing and controlling the optical interface within 458 Black Link scenarios 460 Operation and management of WDM systems is traditionally seen as a 461 homogenous group of tasks that could be carried out best when a 462 single management system or an umbrella management system is used. 463 Currently each WDM vendor provides an Element Management System (EMS) 464 that also administers the wavelengths. 466 Therefore from the operational point of view in a pure Black Link or 467 in a mixed setup with transponders there are the following approaches 468 will be considered to manage and operate optical interfaces. 470 1. Separate operation and management of client device and the 471 transport network 473 a. Direct link between the client device and the management 474 system of the optical network (e.g. EMS, NMS) 475 b. Indirect link to the management system of the optical network 476 using a protocol between the client device and the directly 477 connected WDM system node to exchange management information with 478 the optical domain 480 2. Common operation and management of client device and the 481 Transport network 483 The first option keeps the status quo in large carrier networks as 484 mentioned above. In that case it must be ensured that the full FCAPS 485 Management (Fault, Configuration, Accounting, Performance and 486 Security) capabilities are supported. This means from the management 487 staff point of view nothing changes. The transceiver/receiver 488 optical interface will be part of the optical management domain and 489 will be managed from the transport management staff. 491 The second solution addresses the case where underlying WDM transport 492 network is mainly used to interconnect a homogeneous set of client 493 nodes (e.g. IP routers or digital crossconnects). Since the service 494 creation and restoration could be done by to higher layers (e.g. 495 IP), this may lead to more efficient network operation and a higher 496 level of integration. 498 5.1. BL Separate Operation and Management Approaches 499 5.1.1. Direct connection to the management system 501 As depicted in Figure 3 (case 1a) one possibility to manage the 502 optical interface within the client domain is a direct connection to 503 the management system of the optical domain. This ensures 504 manageability as usual. 506 +-----+ 507 | NMS | 508 |_____| 509 /_____/ 510 | 511 | 512 | 513 +---+---+ 514 +----->+ EMS | 515 / | | 516 / +-------+ 517 / | MI 518 SNMP / | DCN Network 519 --------------------+------------------------------- 520 / +------+-----------------------+ 521 / | +| WDM Domain + | 522 / | |\ /| | 523 +---+--+ | | \ |\ / | | +------+ 524 | CL |-/C------+--- -|OM|----|/-------|OD|--- +-------/C-| CL | 525 | |-/C------+--- -| |----- /|-----| |----+-------/C-| | 526 +------+ | | / \| \ | | +------+ 527 | |/ \| | 528 | + + | 529 +------------------------------+ 531 CL = Client Device 532 /C = G.698.2 Optical Interface 533 OM = Optical Mux 534 OD = Optical Demux 535 EMS = Element Management System 536 MI= Management Interface 538 Figure 3: Connecting G.698.2 optical interfaces to the Transport 539 Management system 541 The exchange of management information between client device and the 542 management system assumes that some form of a direct management 543 communication link exists between the client device and the DWDM 544 management system (e.g. EMS). This may be an Ethernet Link or a DCN 545 connection (management communication channel MCC). 547 It must be ensured that the optical network interface can be managed 548 in a standardized way to enable interoperable solutions between 549 different optical interface vendors and vendors of the optical 550 network management application. RFC 3591 [RFC3591] defines managed 551 objects for the optical interface type but needs further extension to 552 cover the optical parameters required by this framework document. 553 Therefore an extension to this MIB for the optical interface has been 554 drafted in [Black-Link-MIB]. In that case SNMP is used to exchange 555 data between the client device and the management system of the WDM 556 domain. 558 Note that a software update of the optical interface components of 559 the client nodes must not lead obligatory to an update of the 560 software of the EMS and vice versa. 562 5.1.2. Indirect connection to the DWDM management system 564 The alternative as shown in Figure 4 can be used in cases where a 565 more integrated relationship between transport node (e.g. OM or OD) 566 and client device is aspired. In that case a combination of control 567 plane features and manual management will be used. 569 +-----+ 570 | NMS | 571 |_____| 572 /_____/ 573 | 574 | 575 | 576 +---+---+ 577 | EMS | 578 | | 579 +-------+ 580 | MI 581 | 582 | 583 LMP +------+-----------------------+ 584 +------------+---+ +| + | 585 | | | |\ /| | 586 +---+--+ | +-+ \ |\ / | | +------+ 587 | CL |-/C------+--- -|OM|----|/-------|OD|--- +-------/C-| CL | 588 | |-/C------+--- -| |----- /|-----| |----+-------/C-| | 589 +------+ | | / \| \ | | +------+ 590 | |/ \| | 591 | + + | 592 +------------------------------+ 594 CL = Client Device 595 /C = G.698.2 optical Interface 596 OM = Optical Mux 597 OD = Optical Demux 598 EMS= Element Management System 599 MI= Management Interface 601 Figure 4: Direct connection between peer node and first optical 602 network node 604 For information exchange between the client node and the direct 605 connected node of the optical transport network LMP as specified in 606 RFC 4209 [RFC4209] can (should) be used. This extension of LMP may 607 be used between a peer node and an adjacent optical network node as 608 depicted in Figure 4. 610 Recently LMP based on RFC 4209 does not yet support the transmission 611 of configuration data (information). This functionality has to be 612 added to the existing extensions of the protocol. The use of LMP-WDM 613 assumes that some form of a control channel exists between the client 614 node and the WDM equipment. This may be a dedicated lambda, an 615 Ethernet Link, or other signaling communication channel (SCC). 617 5.2. Control Plane Considerations 619 The concept of black link equally applies to management and control 620 plane mechanisms. The general GMPLS control Plane for wavelength 621 switched optical networks is work under definition in the scope of 622 WSON.One important aspect of the BL is the fact that it includes the 623 wavelength that is supported by the given link. Thus a BL can 624 logically be considered as a fiber that is transparent only for a 625 single wavelength. In other words, the wavelength becomes a 626 characteristic of the link itself. Nevertheless the procedure to 627 light up the fiber may vary depending on the BL implementation. 628 Since the implementation of the BL itself is unknown a priori, 629 different sequences to light up wavelength need to be considered: 631 1. Transponders first, transponder tuning: The transmitter is 632 switched on and the BL is immediately transparent to its 633 wavelength. This requires the transmitter to carefully tune 634 power and frequency not overload the line system or to create 635 transients. 637 2. Transponder first, OLS tuning: The transmitter is switched on 638 first and can immediately go to the max power allowed since the 639 OLS performs the power tuning. This leads to an intermediate 640 state where the receiver doesn not receive a valid signal while 641 the transmitter is sending out one. Alarm suppression mechanisms 642 shall be employed to overcome that condition. 644 3. OLS first, Transponder tuning: At first the OLS is tuned to be 645 transparent for a given wavelength, then transponders need to be 646 tuned up. Since the OLS in general requires the presence of a 647 wavelength to fine-tune it is internal facilities there may be a 648 period of time where a valid signal is transmitted but the 649 receiver is unable to detect it. This equally need to be covered 650 by alarm suppression mechanisms. 652 4. OLS first, OLS tuning: The OLS is programmed to be transparent 653 for a given Wavelength, then the transponders need to be switched 654 on and further power tuning takes place. The sequencing of 655 enabling the link needs to be covered as well. 657 The preferred way to address these in a Control Plane enabled network 658 is neighbour discovery including exchange of link characteristics and 659 link property correlation. The general mechanisms are covered in 660 RFC4209 [LMP-WDM] and RFC 4204[LMP] which provides the necessary 661 protocol framework to exchange those characteristics between client 662 and black link. LMP-WDM is not intended for exchanging routing or 663 signalling information but covers: 665 Control channel manangement 667 Link property correlation 669 Link verification 671 Fault Manangement 673 Extensions to LMP/LMP-WDM covering the code points of the BL 674 definition are needed. Additionally when client and server side are 675 managed by different operational entities, Link state exchange is 676 required to align the management systems. 678 5.2.1. Considerations using GMPLS UNI 680 The deployment of G.698.2 optical interfaces is leading to some 681 functional changes related to the control plane models and has 682 therefore some impact on the existing interfaces especially in the 683 case of an overlay model where the edge node requests resources from 684 the core node and the edges node do not participate in the routing 685 protocol instance that runs among the core nodes. RFC 4208 [RFC4208] 686 defines the GMPLS UNI that will be used between edge and core node. 687 In case of a black link deployment additional functionalities are 688 needed to setup a connection. 690 It is necessary to differentiate between topology/signalling 691 information and configuration parameters that are needed to setup a 692 wavelength path. RSVP-TE could be used for the signalling and the 693 reservation of the wavelength path. But there are additional 694 information needed before RSVP-TE can start the signalling process. 695 There are three possibilities to proceed: 697 a. Using RSVP-TE only for the signalling and LMP as described above 698 to exchange information to configure the optical interface within 699 the edge node or 701 b. RSVP-TE will be used to transport additional information 702 c. Leaking IGP information instead of exchanging this information 703 needed from the optical network to the edge node (overlay will be 704 transformed to a border-peer model) 706 Furthermore following issues should be addressed: 708 a) The Communication between peering edge nodes using an out of band 709 control channel. The two nodes have to exchange their optical 710 capabilities. An extended version of LMP is needed to exchange FEC 711 Modulation scheme,etc. that must be the same. It would be helpful to 712 define some common profiles that will be supported. Only if the 713 profiles match with both interface capabilities it is possible start 714 signalling. 716 b) Due to the bidirectional wavelength path that must be setup it is 717 obligatory that the upstream edge node inserts a wavelength value 718 into the path message for the wavelength path towards the upstream 719 node itself. But in the case of an overlay model the client device 720 may not have fullinformation which wavelength must/should be 721 selectedand this information must be exchanged between the edge and 722 the core node. 724 ...additional points 726 6. Requirements for BL deployments 728 This section raises requirements from the carrier perspective and 729 will be removed in a separate requirements draft if necessary. 731 6.1. Interoperability Aspects 733 For carrier network deployments, interoperability is a key 734 requirement. Today it is state-of-the-art to interconnect e.g. 735 client devices from different vendors via a WDM transport system 736 using short-reach, grey interfaces. Applying the Black Link (BL) 737 concept, client devices (e.g. routers) are now directly connected via 738 transport interfaces which must be interoperable to each other. 740 A progressive approach addressing interoperability is shown in 741 Figure 5.According to the concept of ITU-T G.698.2 the black link, 742 the single channel (coloured) Tx and the Rx can be provided different 743 vendors. The single-channel reference points Ss and Rs indicate the 744 demarcation between the Tx/Rx and the black link, and the set of 745 optical parameters refers to these reference points according to 746 G.698.2. However, G.698.2 does not give any insight into the client 747 equipment (CL), e.g. routers or switches, containing the optical 748 transmitters and receivers.This is a valid topic which is subject of 749 other standards and multi-source agreement (MSAs) describing 750 electrical interfaces, mechanical properties and environmental 751 conditions. Such topics are out of the scope of this document. 753 <========= Black Link =========> 754 +---------------------------+ 755 | Black Link | 756 +-----------+ | + + | +-----------+ 757 |CL #1 | -+---|\ /|---+- | CL #2 | 758 | +------+-+ | | \ +-------+ / | | +-+------+ | 759 | -+-| Tx | | | | | | | | | | Rx |-+- | 760 | -+-| +--+-+---|OM|-- OADM |--|OD|---+-+--+ |-+- | 761 | -+-| | Ss | | | | | | | | RS | |-+- | 762 | +------+-+ | | / +-------+ \ | | +-+------+ | 763 | | -+---|/ \|---+- | | 764 | | | + + | | | 765 +-----------+ | | +-----------+ 766 +---------------------------+ 768 CL = Client Device 769 OM = Optical Mux 770 OD = Optical Demux 772 Figure 5: Interoperability aspects 774 7. Acknowledgements 776 The author would like to thank Ulrich Drafz for the very good 777 teamwork during the last years and the initial thoughts related to 778 the packet optical integration. Furthermore the author would like to 779 thank all people involved within Deutsche Telekom for the support and 780 fruitful discussions. 782 8. IANA Considerations 784 This memo includes no request to IANA. 786 9. Security Considerations 788 The architecture and solution space in scope of this framework 789 imposes no additional requirements to the security models already 790 defined in RFC5920 for packet/optical networks using GMPLS, covering 791 also Control Plane and Management interfaces. Respective security 792 mechanisms of the components and protocols, e.g. LMP security 793 models, can be applied unchanged. 795 As this framework is focusing on the single operator use case, the 796 security concerns can be relaxed to a subset compared to a setup 797 where information is exchanged between external parties and over 798 external interfaces. 800 Concerning the access control to Management interfaces, security 801 issues can be generally addressed by authentification techniques 802 providing origin verification, integrity and confidentiality. 803 Additionally, access to Management interfaces can be physically or 804 logically isolated, by configuring them to be only accessible out-of- 805 band, through a system that is physically or logically separated from 806 the rest of the network infrastructure. In case where management 807 interfaces are accessible in-band at the client device or within the 808 optical transport netork domain, filtering or firewalling techniques 809 can be used to restrict unauthorized in-band traffic. Authentication 810 techniques may be additionally used in all cases. 812 10. Contributors 813 Arnold Mattheus 814 Deutsche Telekom 815 Darmstadt 816 Germany 817 email arnold.Mattheus@telekom.de 819 Manuel Paul 820 Deutsche Telekom 821 Berlin 822 Germany 823 email Manuel.Paul@telekom.de 825 Josef Roese 826 Deutsche Telekom 827 Darmstadt 828 Germany 829 email j.roese@telekom.de 831 Frank Luennemann 832 Deutsche Telekom 833 Muenster 834 Germany 835 email Frank.Luennemann@telekom.de 837 11. References 839 11.1. Normative References 841 [ITU G.698.2] International Telecommunications Union, "Amplified 842 multichannel dense wavelength division multiplexing 843 applications with single channel optical 844 interfaces", ITU-T Recommendation G.698.2, 845 November 2009. 847 [ITU.G.872] International Telecommunications Union, 848 "Architecture of optical transport networks", ITU- 849 T Recommendation G.872, November 2001. 851 [ITU.G709] International Telecommunications Union, "Interface 852 for the Optical Transport Network (OTN)", ITU- 853 T Recommendation G.709, March 2003. 855 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 856 Requirement Levels", BCP 14, RFC 2119, March 1997. 858 [RFC3591] Lam, H-K., Stewart, M., and A. Huynh, "Definitions 859 of Managed Objects for the Optical Interface Type", 860 RFC 3591, September 2003. 862 [RFC4204] Lang, J., "Link Management Protocol (LMP)", 863 RFC 4204, October 2005. 865 [RFC4209] Fredette, A. and J. Lang, "Link Management Protocol 866 (LMP) for Dense Wavelength Division Multiplexing 867 (DWDM) Optical Line Systems", RFC 4209, 868 October 2005. 870 11.2. Informative References 872 [Black-Link-MIB] Internet Engineering Task Force, "A SNMP MIB to 873 manage black-link optical interface parameters of 874 DWDM applications", draft-galimbe-kunze-g-698-2- 875 snmp-mib draft-galimbe-kunze-g-698-2-snmp-mib, 876 July 2011. 878 [ITU-T G.691] ITU-T, "Optical interfaces for single channel 879 STM-64 and other SDH systems with optical 880 amplifiers", ITU-T Recommendation ITU-T G.691, 881 2008. 883 [ITU-T G.693] ITU-T, "Optical interfaces for intra-office 884 systems", ITU-T Recommendation ITU-T G.693, 2009. 886 [ITU-T G.8081] ITU-T, "Terms and definitions for Automatically 887 Switched Optical Networks (ASON)", ITU-T 888 Recommendation G.8081", ITU-T Recommendation ITU-T 889 G.8081, September 2010. 891 [ITU-T G.957] ITU-T, "Optical interfaces for equipments and 892 systems relating to the synchronous digital 893 hierarchy", ITU-T Recommendation ITU-T G.957, 2006. 895 [ITU-T G.959.1] ITU-T, "Optical transport network physical layer 896 interfaces", ITU-T Recommendation ITU-T G.959.1, 897 2009. 899 Authors' Addresses 901 Ruediger Kunze (editor) 902 Deutsche Telekom AG 903 Berlin, 10589 904 DE 906 Phone: +49 30 3497 3152 907 EMail: ruediger.kunze@telekom.de 909 Gert Grammel (editor) 910 Juniper Networks 911 ddddd 912 dddd, 1234 913 US 915 Phone: +1 45552 916 EMail: ggrammel@juniper.net 918 Gabriele Galimberti (editor) 919 Cisco 920 Via Philips,12 921 20052 - Monza 922 Italy 924 Phone: +390392091462 925 EMail: ggalimbe@cisco.com 927 Hans-Juergen Schmidtke (editor) 928 Juniper Networks 929 dddd, 1234 930 US 932 Phone: +1 45552 933 EMail: hschmidtke@juniper.net