idnits 2.17.1 draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-11.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (June 11, 2018) is 2138 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC6241' is mentioned on line 957, but not defined == Missing Reference: 'RFC8040' is mentioned on line 958, but not defined Summary: 0 errors (**), 0 flaws (~~), 4 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: December 13, 2018 Juniper 6 D. Beller 7 Nokia 8 G. Galimberti, Ed. 9 Cisco 10 J. Meuric 11 Orange 12 June 11, 2018 14 A framework for Management and Control of DWDM optical interface 15 parameters 16 draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-11 18 Abstract 20 The control and management of DWDM interfaces are a precondition for 21 enhanced multilayer networking. They are needed to ensure an 22 efficient data transport, to meet the requirements requested by 23 today's IP-services and to provide a further automation of network 24 provisioning and operations. This document describes use cases, 25 requirements and solutions for the control and management of optical 26 interface parameters according to different types of single channel 27 DWDM interfaces. The focus is on automating the network provisioning 28 process irrespective on how it is triggered i.e. by Element Manager 29 System (EMS), Network Management System (NMS) or Generalized Multi 30 Protocol Label Switching (GMPLS). This document covers management 31 and control considerations in different scenarios of single channel 32 DWDM interfaces. The purpose is to identify the necessary 33 information and processes to be used by control or management systems 34 to properly and efficiently drive the network. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at https://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on December 13, 2018. 53 Copyright Notice 55 Copyright (c) 2018 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (https://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 71 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 72 2. Terminology and Definitions . . . . . . . . . . . . . . . . . 4 73 3. Solution Space . . . . . . . . . . . . . . . . . . . . . . . 5 74 3.1. Comparison of Approaches for Transverse Compatibility . . 6 75 3.1.1. Multivendor DWDM Line System with Transponders . . . 6 76 3.1.2. Integrated Single Channel DWDM Deployments on the 77 Client Site . . . . . . . . . . . . . . . . . . . . . 7 78 4. Solutions for Managing and Controlling Single Channel Optical 79 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 9 80 4.1. Separate Operation and Management Approaches . . . . . . 10 81 4.1.1. Direct Connection to the Management System . . . . . 10 82 4.1.2. Indirect Connection to the DWDM Management System 83 (First Optical Node) . . . . . . . . . . . . . . . . 11 84 4.2. Control Plane Considerations . . . . . . . . . . . . . . 13 85 4.2.1. Considerations Using GMPLS Signaling . . . . . . . . 14 86 5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 15 87 5.1. Service Setup . . . . . . . . . . . . . . . . . . . . . . 15 88 5.2. Link Monitoring Use Cases . . . . . . . . . . . . . . . . 16 89 5.2.1. Pure Access Link (AL) Monitoring Use Case . . . . . . 19 90 5.2.2. Power Control Loop Use Case . . . . . . . . . . . . . 21 91 6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 23 92 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 93 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 94 9. Security Considerations . . . . . . . . . . . . . . . . . . . 25 95 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25 96 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 97 11.1. Normative References . . . . . . . . . . . . . . . . . . 26 98 11.2. Informative References . . . . . . . . . . . . . . . . . 28 99 Appendix A. Appendix . . . . . . . . . . . . . . . . . . . . . . 29 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 102 1. Introduction 104 The usage of external single channel Dense Wavelenght Division 105 Multiplexing (DWDM) interfaces (e.g. in routers) connected to a DWDM 106 Network (e.g. router connected to a network of Reconfigurable Optical 107 Add Drop Multiplexers (ROADM) and optical amplifiers) adds a further 108 networking option for operators but requires an harmonised control 109 and management plane interaction between the different network 110 domains. 112 Carriers deploy their networks today based on transport and packet 113 network infrastructures as domains to ensure high availability and a 114 high level of redundancy combining the Packet and Transport 115 restoration. Both network domains were operated and managed 116 separately. This is the status quo in many carrier networks today. 117 In the case of deployments where the optical transport interface 118 moves into the client device (e.g. router) an interaction between 119 those domains becomes necessary (e.g. Lambda reprovisioning due to 120 an optical restoration). 122 This framework specifies different levels of control and management 123 plane interaction to support the usage of single channel optical 124 interfaces in carrier networks in an efficient manner. The 125 interfaces between the two layers can be either gray or coloured. 127 Although Optical routing and wavelength assignment based on 128 Wavelenght Switched Optical Network (WSON) is out of scope, they can 129 benefit from the optical parameters that are exchanged between the 130 Client and the DWDM Network. Also, the wavelength ordering process 131 and determining the demand for a new wavelength path through the 132 network are out of scope. The GMPLS and PCE functions will use the 133 information collected from the Client and the DWDM network, the 134 definition on how PCE and GMPLS can use the information and cooperate 135 to implement RWA and circuit/service provisioning ar aout of scope of 136 this document. 138 Note that the Control and Management Planes are two separate entities 139 that may handle the same information in different ways. 141 1.1. Requirements Language 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 145 "OPTIONAL" in this document are to be interpreted as described in 146 BCP_14, RFC 2119 [RFC2119], RFC 8174 [RFC8174] when, and only when, 147 they appear in all capitals, as shown here. 149 While RFC 2119 [RFC2119] RFC 8174 [RFC8174] describe interpretations 150 of these key words in terms of protocol specifications and 151 implementations, they are used in this document to describe design 152 requirements for protocol extensions. 154 2. Terminology and Definitions 156 The current generation of Wavelenght Division Multiplexing (WDM) 157 networks are single vendor networks where the optical line system and 158 the transponders are tightly integrated. The DWDM interface 159 migration from integrated transponders to third party transponders or 160 colored interfaces change this scenario and introduces a standardized 161 interface at the level of OCh between the DWDM interface and the DWDM 162 network. 164 Black Link: The Black Link [ITU-T.G.698.2] allows supporting an 165 optical transmitter/receiver pair (of a single vendor or from 166 different vendors) to provide a single optical channel interface and 167 transport it over an optical network composed of amplifiers, filters, 168 add-drop multiplexers these being possibly from different vendors. 169 Therefore the standard defines the ingress and egress parameters for 170 the optical interfaces at the reference points Source side (Ss) and 171 Receive side (Rs). 173 Single Channel DWDM Interface: The single channel interfaces to DWDM 174 systems defined in [ITU-T.G.698.2], which currently include the 175 following features: channel frequency spacing: 50 GHz and wider 176 (defined in [ITU-T.G.694.1] ); bit rate of single channel: Up to 10 177 Gbit/s. Future revisions are expected to include application codes 178 for bit rates up to 40 Gb/s. 180 Forward Error Correction (FEC): FEC is a way of improving the 181 performance of high-capacity optical transmission systems. Employing 182 FEC in optical transmission systems yields system designs that can 183 accept relatively large BER (much more than 10^-12) in the optical 184 transmission line (before decoding). 186 Administrative domain [ITU-T.G.805]: the extent of resources which 187 belong to a single player such as a network operator, a service 188 provider or an end-user. Administrative domains of different players 189 do not overlap amongst themselves. 191 Intra-domain interface (IaDI) [ITU-T.G.872]: A physical interface 192 within an administrative domain. 194 Inter-domain interface (IrDI) [ITU-T.G.872]: A physical interface 195 that represents the boundary between two administrative domains. 197 Management Plane [ITU-T.G.8081],: The management plane performs 198 management functions for the transport plane, the control plane and 199 the system as a whole. It also provides coordination between all the 200 planes. The following management functional areas are performed in 201 the management plane: performance management, fault management, 202 configuration management, accounting management and security 203 management. 205 Control Plane [ITU-T.G.8081]: Through signaling, the control plane 206 sets up and releases connections, may restore a connection in case of 207 a failure, and also performs other functions (e.g., neighbor 208 discovery, topology distribution) in support of those. 210 Transponder: A Transponder is a network element that performs O/E/O 211 (Optical /Electrical/Optical) conversion. In this document it is 212 referred only transponders with 3R (rather than 2R or 1R 213 regeneration) as defined in [ITU-T.G.872]. 215 Line System: A Line System is a portion of the network including 216 Reconfigurable Add Drop Multiplexers (ROADM) Line Amplifiers and the 217 the fibers connecting them. 219 Client DWDM interface: A Transceiver element that performs E/O 220 (Electrical/Optical) conversion. In this document it is referred as 221 the DWDM side of a transponder as defined in [ITU-T.G.872]. 223 3. Solution Space 225 The solution space of this document is focusing on aspects related to 226 the management and control of single-channel optical interface 227 parameters of physical point-to-point and ring DWDM applications on 228 single-mode optical fibres and allows the direct connection of a wide 229 variety of equipment using a DWDM link, for example 231 1. A digital cross-connect with multiple optical interfaces, 232 supplied by a different vendor from the line system 234 2. Devices as routing, switching or compute nodes, each from a 235 different vendor, providing optical line interfaces 237 3. A combination of the above 239 3.1. Comparison of Approaches for Transverse Compatibility 241 This section describes two ways to achieve transverse compatibility. 242 Section 3.1.1 describes the classic model based on well defined 243 inter-domain interfaces. Section 3.1.2 defines a model ensuring 244 interoperability on the line side of the optical network. 246 3.1.1. Multivendor DWDM Line System with Transponders 248 As illustrated in Figure 1, for this approach interoperability is 249 achieved via the use of optical transponders providing OEO (allowing 250 conversion to appropriate parameters). The optical interfaces can 251 then be any short reach standardized optical interface that both 252 vendors support, such as those found in [ITU-T.G.957], [ITU-T.G.691], 253 [ITU-T.G.693], etc. 255 IrDI IaDI 256 | | 257 . . 258 | +----------------------------|----+ 259 . | + WDM Domain + . | 260 | | |\ /| | | 261 +------+ . | | \ |\ / | . | +------+ 262 | TX/ |-->--+---+--T/-|OM|----|/-------|OD|--+-\T-+---->--| RX/ | 263 | RX |--<--+---+--T/-| |----- /|-----| |--.-\T-+----<--| TX | 264 +------+ | | | / \| \ | | | +------+ 265 . | |/ \| . | 266 | | + + | | 267 . +----------------------------.----+ 268 | | 270 TX/RX = Single channel non-DWDM interfaces 271 T/ = Transponder 272 OM = Optical Mux 273 OD = Optical Demux 275 Figure 1: Inter and Intra-Domain Interface Identification 277 In the scenario of Figure 1 the administrative domain is defined by 278 the Interdomain Interface (IrDI). This interface terminates the DWDM 279 domain. The line side is characterized by the IaDI. This interface 280 specifies the internal parameter set of the optical administrative 281 domain. In the case of a client DWDM interface deployment this 282 interface moves into the client device and extends the optical and 283 administrative domain towards the client node. [ITU-T.G.698.2] for 284 example specifies a set of parameter set for a certain set of 285 applications. 287 This document elaborates only the IaDI (Intra Domain Interface) as 288 shown in Figure 1 as DWDM transversely compatible and multi-vendor 289 interface within one administrative domain controlled by the network 290 operator. 292 SNMP/Simple Management Interface (SMI), NETCONF/RESTCONF and Link 293 Management Protocol (LMP) TLV to support the direct exchange of 294 information between the client and the network management and control 295 plane will be specified in further documents. 297 The YANG based NETCONF and RESTCONF protocol are better suited for 298 creating and modifying configuration state and thus RECOMMENDED to be 299 used over SNMP MIB. The SNMP MIB creating and modifying 300 configuration state could be used for legacy network. 302 3.1.2. Integrated Single Channel DWDM Deployments on the Client Site 304 In case of a deployment as shown in Figure 2, through the use of DWDM 305 interfaces, multi-vendor interconnection can also be achieved. Among 306 the possible use cases, it may be used to remove the need for one 307 short reach transmitter and receiver pair per channel (eliminating 308 the transponders). 310 Figure 2 shows a set of reference points, for single-channel 311 connection (Ss and Rs) between transmitters (Tx) and receivers (Rx). 312 Here the DWDM network elements include an optical multiplexer (OM) 313 and an optical demultiplexer (OD) (which are used as a pair with the 314 peer element), one or more optical amplifiers and may also include 315 one or more ROADMs. 317 |==================== Black Link =======================| 319 +-------------------------------------------------+ 320 Ss | | DWDM Network Elements | | Rs 321 +---+ | | | \ / | | | +---+ 322 Tx L1---|->| \ +------+ +------+ / |--|-->Rx L1 323 +---+ | | | | | +------+ | | | | | +---+ 324 +---+ | | | | | | | | | | | | +---+ 325 Tx L2---|->| OM |-|>|------|->| ROADM|--|------|->| OD |--|-->Rx L2 326 +---+ | | | | | | | | | | | | +---+ 327 +---+ | | | | | +------+ | | | | | +---+ 328 Tx L3---|->| / | DWDM | | ^ | DWDM | \ |--|-->Rx L3 329 +---+ | | / | Link +----|--|----+ Link | \ | | +---+ 330 +-----------+ | | +----------+ 331 +--+ +--+ 332 |==== Black Link ====| | | 333 v | 334 +-----+ +-----+ 335 |RxLx | |TxLx | 336 +-----+ +-----+ 338 Ss = Reference point at the DWDM network element tributary output 339 Rs = Reference point at the DWDM network element tributary input 340 Lx = Lambda x 341 OM = Optical Mux 342 OD = Optical Demux 343 ROADM = Reconfigurable Optical Add Drop Mux 345 Linear DWDM network as per ITU-T G.698.2 347 Figure 2: Linear Black Link 349 The single administrative domain may consist of several vendor 350 domains. Even in that case a common network management and control 351 is required to ensure a consistent operation and provisioning of the 352 entire connection. 354 SNMP/SMI, NETCONF/RESTCONF and LMP TLV to support the direct exchange 355 of information between the client and the network management and 356 control plane will be specified in further documents. 358 4. Solutions for Managing and Controlling Single Channel Optical 359 Interface 361 Operation and management of WDM systems is traditionally seen as a 362 homogenous group of tasks that could be carried out best when a 363 single management system or a hierarchical management system is used. 364 Currently each WDM vendor provides an Element Management System (EMS) 365 that also provisions the wavelengths. In a multi-vendor line system, 366 such single-vendor EMS requirement is no more effective. New methods 367 of managing and controlling line systems need to be looked at. 369 Therefore from the operational point of view the following approaches 370 will be considered to manage and operate optical interfaces. 372 1. Separate operation and management of client device and the 373 transport network whereas the interface of the client belongs to 374 the administrative domain of the transport network and will be 375 managed by the transport group. This results in two different 376 approaches to send information to the management system 378 a. Direct connection from the client node to the transport 379 management system, ensuring a management of the DWDM interface of 380 the optical network (e.g. EMS, NMS) 382 b. Indirect connection to the management system of the optical 383 network using a protocol (e.g. LMP) between the client device 384 and the directly connected WDM system node to exchange management 385 information with the optical domain 387 2. Common operation and management of client device including the 388 single channel DWDM part and the Transport network 390 The first option keeps the status quo in large carrier networks as 391 mentioned above. In that case it must be ensured that the full FCAPS 392 Management (Fault, Configuration, Accounting, Performance and 393 Security) capabilities are supported. This means from the management 394 staff point of view nothing changes. The transceiver/receiver 395 optical interface will be part of the optical management domain and 396 will be managed from the transport management staff. 398 The second solution addresses the case where underlying WDM transport 399 network is mainly used to interconnect a homogeneous set of client 400 nodes (e.g. IP routers or digital crossconnects). Since the service 401 creation and restoration could be done by the higher layers (e.g. 403 IP), this may lead to an efficient network operation and a higher 404 level of integration. 406 4.1. Separate Operation and Management Approaches 408 4.1.1. Direct Connection to the Management System 410 As depicted in Figure 3 (case 1a) one possibility to manage the 411 optical interface within the client domain is a direct connection to 412 the management system of the optical domain. This ensures 413 manageability as usual. 415 +-----+ 416 | NMS | 417 |_____| 418 /_____/ 419 | 420 | 421 | 422 +---+---+ 423 +----->+ EMS | 424 / | | 425 / +-------+ 426 / | MI SNMP or NETCONF/RESTCONF 427 SNMP / or NETCONF | DCN Network 428 --------------------+------------------------------- 429 / +------+-----------------------+ 430 / | +| WDM Domain + | 431 / | |\ /| | 432 +---+--+ | | \ |\ / | | +------+ 433 | CL |-/C------+-----|OM|----|/-------|OD|----+-------/C-| CL | 434 | |-/C------+-----| |----- /|-----| |----+-------/C-| | 435 +------+ | | / \| \ | | +------+ 436 | |/ \| | 437 | + + | 438 +------------------------------+ 440 CL = Client Device 441 /C = Single Channel Optical Interface 442 OM = Optical Mux 443 OD = Optical Demux 444 EMS = Element Management System 445 MI = Management Interface 446 DCN = Data Control Network 448 Figure 3: Connecting Single Channel optical interfaces to the 449 Transport Management system 451 The exchange of management information between client device and the 452 management system assumes that some form of a direct management 453 communication link exists between the client device and the DWDM 454 management system (e.g. EMS). This may be an Ethernet Link or a DCN 455 connection (management communication channel MCC). 457 It must be ensured that the optical network interface can be managed 458 in a standardized way to enable interoperable solutions between 459 different optical interface vendors and vendors of the optical 460 network management application. [RFC3591] defines managed objects 461 for the optical interface type but needs further extension to cover 462 the optical parameters required by this framework document. 464 Is to be noted that the CL (client device) and the DWDM network are 465 belonging to the same operator so the DWDM EMS and the Client devices 466 are connected to the same DCN and the communication security 467 considerations are applicable to CL as per DWDM devices. 469 Note that a software update of the optical interface components of 470 the client nodes must not lead obligatory to an update of the 471 software of the EMS and vice versa. 473 4.1.2. Indirect Connection to the DWDM Management System (First Optical 474 Node) 476 An alternative as shown in Figure 4 should be used in cases where a 477 more integrated relationship between transport node (e.g. OM or OD 478 or ROADM) and client device is aspired. In that case a combination 479 of control plane features and manual management will be used. 481 +-----+ 482 | NMS | 483 |_____| 484 /_____/ 485 | 486 | 487 +---+---+ 488 | EMS | 489 | | 490 +-------+ 491 | MI SNMP or NETCONF/RESTCONF 492 | 493 LMP +------+-----------------------+ 494 +------------+---+ +| + | 495 | | | |\ /| | 496 +---+--+ | +-+ \ |\ / | | +------+ 497 | CL |-/C------+--- -|OM|----|/-------|OD|--- +-------/C-| CL | 498 | |-/C------+--- -| |----- /|-----| |----+-------/C-| | 499 +------+ | | / \| \ | | +------+ 500 | |/ \| | 501 | + + | 502 +------------------------------+ 504 CL = Client Device 505 /C = Single Channel optical Interface 506 OM = Optical Mux 507 OD = Optical Demux 508 EMS= Element Management System 509 MI= Management Interface 511 Figure 4: Direct connection between peer node and first optical 512 network node 514 For information exchange between the client node and the direct 515 connected node of the optical transport network LMP as specified in 516 RFC 4209 [RFC4209] should be used. This extension of LMP may be used 517 between a peer node and an adjacent optical network node as depicted 518 in Figure 4. 520 At the time of writing this document, LMP does not yet support the 521 transmission of configuration data (information). This functionality 522 would need to be added to the protocol. The use of LMP assumes that 523 some form of a control channel exists between the client node and the 524 WDM equipment. This may be a dedicated lambda or an Ethernet Link. 526 4.2. Control Plane Considerations 528 The concept of integrated single channel DWDM interfaces equally 529 applies to management and control plane mechanisms. GMPLS control 530 plane protocols have been extended for WSON, e.g. RFC 7689 [RFC7689] 531 ) for fixed grid signal and for flexi-grid RFC 7792 [RFC7792] ). One 532 important aspect of the Black Link [ITU-T.G.698.2] is the fact that 533 it includes the wavelength that is supported by the given link. 534 Therefore, the link can logically be considered as a fiber that is 535 transparent only for a single wavelength. In other words, the 536 wavelength becomes a characteristic of the link itself. 538 Nevertheless the procedure to light up the fiber may vary depending 539 on the implementation. Since the implementation is unknown a priori, 540 different sequences to light up a wavelength need to be considered: 542 1. Interface first, interface tuning: The transmitter is switched on 543 and the link is immediately transparent to its wavelength. This 544 requires the transmitter to carefully tune power and frequency 545 not overload the line system or to create transients. 547 2. Interface first, Optical Line System (OLS) tuning: The 548 transmitter is switched on first and can immediately go to the 549 max power allowed since the OLS performs the power tuning. This 550 leads to an intermediate state where the receiver does not 551 receive a valid signal while the transmitter is sending out one. 552 Alarm suppression mechanisms shall be employed to overcome that 553 condition. 555 3. OLS first, interface tuning: At first the OLS is tuned to be 556 transparent for a given wavelength, then transponders need to be 557 tuned up. Since the OLS in general requires the presence of a 558 wavelength to fine-tune its internal facilities there may be a 559 period where a valid signal is transmitted but the receiver is 560 unable to detect it. This equally need to be covered by alarm 561 suppression mechanisms. 563 4. OLS first, OLS tuning: The OLS is programmed to be transparent 564 for a given wavelength, then the interfaces need to be switched 565 on and further power tuning takes place. The sequencing of 566 enabling the link needs to be covered as well. 568 The preferred way to address these in a Control Plane enabled network 569 is neighbour discovery including exchange of link characteristics and 570 link property correlation. The general mechanisms are covered in RFC 571 4209 [RFC4209] and RFC 4204 [RFC4204] which provides the necessary 572 protocol framework to exchange those characteristics between client 573 and Black Link. LMP-WDM is not intended for exchanging routing or 574 signaling information nor to provision the lambda in the transceiver 575 but covers: 577 1. Control channel management 579 2. Link property correlation 581 3. Link verification 583 4. Fault management 585 Extensions to LMP covering the parameter sets (e.g. application 586 codes) are needed. Additionally, when client and server side are 587 managed by different operational entities, the link state may be 588 useful to help the management system to do troubleshooting or alarm 589 correlation. 591 4.2.1. Considerations Using GMPLS Signaling 593 The deployment of single channel optical interfaces is leading to 594 some functional changes related to the control plane models and has 595 therefore some impact on the existing interfaces especially in the 596 case of a model where the edge node requests resources from the core 597 node and the edge node do not participate in the routing protocol 598 instance that runs among the core nodes. RFC 4208 [RFC4208] defines 599 the GMPLS UNI that can be used between edge and core node. In case 600 of integrated interfaces deployment additional functionalities are 601 needed to setup a connection. 603 It is necessary to differentiate between topology/signalling 604 information and configuration parameters that are needed to setup a 605 wavelength path. Using RSVP-TE could be used for the signalling and 606 the reservation of the wavelength path. But there are additional 607 information needed before RSVP-TE can start the signalling process. 608 There are three possibilities to proceed: 610 a. Using RSVP-TE only for the signalling and LMP as described above 611 to exchange information on the configured optical interface 612 within the edge node 614 b. RSVP-TE (typically with loose ERO) to transport additional 615 information 617 c. Leaking IGP information instead of exchanging this information 618 needed from the optical network to the edge node (UNI will be 619 transformed to a border-peer model, see RFC 5146 [RFC5146] ) 621 Furthermore following issues should be addressed: 623 a) The transceivers of peering edge nodes must be compatible. For 624 example, it may be required to know about FEC, modulation scheme, The 625 modulation format, the baudrate and many other parameters described 626 in the drafts reported in the Annex. Depending on where the 627 information is available, compatibility check may either happen 628 before signaling, when the signaling reaches the optical network 629 (e.g. at path computation time), or in the tail end node. An 630 extended version of LMP is needed to exchange this information in 631 case a. above, and to RSVP-TE as well in b. It would be helpful to 632 define some common profiles that will be supported (e.g. the 633 "application identifier") to summarize interface capabilities: if 634 both profiles match, signaling can succeed and provisioning be 635 achieved. 637 b) Due to the bidirectional wavelength path that must be setup, the 638 upstream edge node must include a wavelength value into the RSVP-TE 639 Path message. But in the case of a UNI model the client device may 640 not have full information about which wavelength must/should be 641 selected, whereas this information must be exchanged between the edge 642 and the core node. The special value defined in 643 [Network-Assigned-Upstream-Label] allows the optical network to 644 assign the actual wavelength to be used by the upstream transponder, 645 which is a simple and efficient solution to this issue. 647 5. Use Cases 649 A comparison with the traditional operation scenarios provides an 650 insight of similarities and distinctions in operation and management 651 of DWDM interfaces. The following use cases provide an overview 652 about operation and maintenance processes. 654 5.1. Service Setup 656 It is necessary to differentiate between different operational issues 657 for setting up a light path (a DWDM connection is specific in having 658 defined maximum impairments) within an operational network. 660 The first step is to determine if transceivers located at different 661 end-points are interoperable, i.e. support a common set of 662 operational parameters. In this step it is required to determine 663 transceiver capabilities in a way to be able to correlate them for 664 interoperability purposes. Such parameters include modulation 665 scheme, modulation parameters, FEC to name a few. If both 666 transceivers are controlled by the same NMS or CP, such data is 667 readily available. However in cases like Figure 4, a protocol needs 668 to be used to inform the controlling instance (NMS or CP) about 669 transceiver parameters. It is suggested to extend LMP for that 670 purpose. 672 The second step is to determine the feasibility of a lightpath 673 between two transceivers without applying an optical signal. 674 Understanding the limitations of the transceiver pair, a path through 675 the optical network has to be found, whereby each path has an 676 individual set of impairments deteriorating a wavelength traveling 677 along that path. Since a single transceiver can support multiple 678 parameter sets, the selection of a path may limit the permissible 679 parameter sets determined in previous steps. 681 The third step is then to setup the connection itself and to 682 determine the Wavelength. This is done using the NMS of the optical 683 transport network or by means of a control plane interaction such as 684 signaling and includes the path information as well as the parameter 685 set information necessary to enable communication. 687 In a fourth step, optical monitoring is activated in the WDM network 688 in order to monitor the status of the connection. The monitor 689 functions of the optical interfaces at the terminals are also 690 activated in order to monitor the end to end connection. 692 Furthermore it should be possible to automate this step. After 693 connecting the client device to the neighbor control plane-enabled 694 transport node, a control adjacency may be automatically established, 695 e.g. using LMP. 697 5.2. Link Monitoring Use Cases 699 The use cases described below are assuming that power monitoring 700 functions are available in the ingress and egress network element of 701 the DWDM network, respectively. By performing link property 702 correlation it would be beneficial to include the current transmit 703 power value at reference point Ss and the current received power 704 value at reference point Rs. For example if the Client transmitter 705 power has a value of 0dBm and the ROADM interface measured power is 706 -6dBm the fiber patch cord connecting the two nodes may be pinched or 707 the connectors are dirty. As discussed before, the actual path or 708 selection of a specific wavelength within the allowed set is outside 709 the scope of LMP. The computing entities (e.g. the first optical 710 node originating the circuit) can rely on GMPLS IGP (OSPF) to 711 retrieve all the information related to the network, calculate the 712 path to reach the endpoint and signal the path implementation through 713 the network via RSVP-TE. 715 [ITU-T.G.698.2] defines a single channel optical interface for DWDM 716 systems that allows interconnecting network-external optical 717 transponders across a DWDM network. The optical transponders are 718 external to the DWDM network. This so-called 'Black Link' approach 719 illustrated in Fig. 5-1 of [ITU-T.G.698.2] and a copy of this figure 720 is provided below in Figure 5. The single channel fiber link between 721 the Ss/Rs reference points and the ingress/egress port of the network 722 element on the domain boundary of the DWDM network (DWDM border NE) 723 is called access link. Based on the definition in [ITU-T.G.698.2] it 724 is part of the DWDM network. The access link is typically realized 725 as a passive fiber link that has a specific optical attenuation 726 (insertion loss). As the access link is an integral part of the DWDM 727 network, it is desirable to monitor its attenuation. Therefore, it 728 is useful to detect an increase of the access link attenuation, for 729 example, when the access link fiber has been disconnected and 730 reconnected (maintenance) and a bad patch panel connection 731 (connector) resulted in a significantly higher access link 732 attenuation (loss of signal in the extreme case of an open connector 733 or a fiber cut). In the following section, two use cases are 734 presented and discussed: 736 1) pure access link monitoring 737 2) access link monitoring with a power control loop 739 These use cases require a power monitor as described in G.697 (see 740 section 6.1.2), that is capable to measure the optical power of the 741 incoming or outgoing single channel signal. The use case where a 742 power control loop is in place could even be used to compensate an 743 increased attenuation if the optical transmitter can still be 744 operated within its output power range defined by its application 745 code. 747 Use case 1: Access Link monitoring 749 +--------------------------+ 750 | P(in) = P(Tx) - a(Tx) | 751 | ___ | 752 +----------+ | \ / Power Monitor | 753 | | P(Tx) | V P(in) | 754 | +----+ | Ss //\\ | | |\ | 755 | | TX |----|-----\\//------------------->| \ | 756 | +----+ | Access Link (AL-T) | . | | | 757 | | attenuation a(Tx) | . | |==============> 758 | | | . | | | 759 | External | | --->| / | 760 | Optical | | |/ | 761 |Transpond.| | P(out) | 762 | | | ___ | 763 | | | \ / Power Monitor | 764 | | P(Rx) | V P(out) | 765 | +----+ | Rs //\\ | | |\ | 766 | | RX |<---|-----\\//--------------------| \ | 767 | +----+ | Access Link (AL-R) | . | | | 768 | | Attenuation a(Rx) | . | |<============== 769 +----------+ | . | | | 770 | <---| / | 771 P(Rx) = P(out) - a(Rx) | |/ | 772 | | 773 | ROADM | 774 +--------------------------+ 776 - For AL-T monitoring: P(Tx) and a(Tx) must be known 777 - For AL-R monitoring: P(RX) and a(Rx) must be known 779 An alarm shall be raised if P(in) or P(Rx) drops below a 780 configured threshold (t [dB]): 781 - P(in) < P(Tx) - a(Tx) - t (Tx direction) 782 - P(Rx) < P(out) - a(Rx) - t (Rx direction) 783 - a(Tx) =| a(Rx) 785 Alarms and events can be shared between Client and Network 786 via LMP. 788 Figure 5: Access Link Power Monitoring 790 5.2.1. Pure Access Link (AL) Monitoring Use Case 792 Figure 6 illustrates the access link monitoring use case and the 793 different physical properties involved that are defined below: 795 - Ss, Rs: Single Channel reference points 796 - P(Tx): current optical output power of transmitter Tx 797 - a(Tx): access link attenuation in Tx direction (external 798 transponder point of view) 799 - P(in): measured current optical input power at the input port 800 of border DWDM NE 801 - t: user defined threshold (tolerance) 802 - P(out): measured current optical output power at the output port 803 of border DWDM NE 804 - a(Rx): access link attenuation in Rx direction (external 805 transponder point of view) 806 - P(Rx): current optical input power of receiver Rx 808 Description: 809 - The access link attenuation in both directions (a(Tx), a(Rx)) 810 is known or can be determined as part of the commissioning 811 process. Typically, both values are very similar. 812 - A threshold value t has been configured by the operator. This 813 should also be done during commissioning. 814 - A control plane protocol is in place that allows 815 to periodically send the optical power values P(Tx) and P(Rx) 816 to the control plane protocol instance on the DWDM border NE. 817 This is illustrated in Figure 3. 818 - The DWDM border NE is capable to periodically measure the optical 819 power P(in) and P(out) as defined in G.697 by power monitoring 820 points depicted as triangles in the figures below. 822 Access Link monitoring process: 823 - Tx direction: the measured optical input power P(in) is compared 824 with the expected optical input power P(Tx) - a(Tx). If the 825 measured optical input power P(in) drops below the value 826 (P(Tx) - a(Tx) - t) a low power alarm shall be raised indicating 827 that the access link attenuation has exceeded a(Tx) + t. 828 - Rx direction: the measured optical input power P(Rx) is 829 compared with the expected optical input power P(out) - a(Rx). 830 If the measured optical input power P(Rx) drops below the value 831 (P(out) - a(Rx) - t) a low power alarm shall be raised indicating 832 that the access link attenuation has exceeded a(Rx) + t. 833 - to avoid toggling errors, the low power alarm threshold shall be 834 lower than the alarm clear threshold. 836 Use case 2: Access Link monitoring through LMP 838 +----------+ +--------------------------+ 839 | +------+ | P(Tx), P(Rx) | +-------+ | 840 | | | | =================> | | | | 841 | | LMP | | P(in), P(out) | | LMP | | 842 | | Agent| | <================= | | Agent | | 843 | +------+ | | +-------+ | 844 | | | | 845 | | | P(in) - P(Tx) - a(Tx) | 846 | | | ___ | 847 | | | \ / Power Monitor | 848 | | P(Tx) | V | 849 | +----+ | Ss //\\ | | |\ | 850 | | TX |----|-----\\//------------------->| \ | 851 | +----+ | Access Link (AL-T) | . | | | 852 | | attenuation a(Tx) | . | |==============> 853 | | | . | | | 854 | External | | --->| / | 855 | Optical | | |/ | 856 |Transpond.| | P(out) | 857 | | | ___ | 858 | | | \ / Power Monitor | 859 | | P(Rx) | V | 860 | +----+ | Rs //\\ | | |\ | 861 | | RX |<---|-----\\//--------------------| \ | 862 | +----+ | Access Link (AL-R) | . | | | 863 | | Attenuation a(Rx) | . | |<============== 864 +----------+ | . | | | 865 | <---| / | 866 P(Rx) = P(out) - a(Rx) | |/ | 867 | | 868 | ROADM | 869 +--------------------------+ 871 - For AL-T monitoring: P(Tx) and a(Tx) must be known 872 - For AL-R monitoring: P(RX) and a(Rx) must be known 873 An alarm shall be raised if P(in) or P(Rx) drops below a 874 configured threshold (t [dB]): 875 - P(in) < P(Tx) - a(Tx) - t (Tx direction) 876 - P(Rx) < P(out) - a(Rx) - t (Rx direction) 877 - a(Tx) = a(Rx) 879 Alarms and events can be shared between Client and Network 880 via LMP according to [RFC4204] and [RFC4209] 881 Figure 6: Extended LMP Model 883 5.2.2. Power Control Loop Use Case 885 This use case is based on the access link monitoring as 886 described above. In addition, the border NE is running a power 887 control application that is capable to control the optical output 888 power of the single channel tributary signal at the output port 889 of the border DWDM NE (towards the external receiver Rx) and the 890 optical output power of the single channel tributary signal at 891 the external transmitter Tx within their known operating range. 892 The time scale of this control loop is typically relatively slow 893 (e.g. some 10s or minutes) because the access link attenuation 894 is not expected to vary much over time (the attenuation only 895 changes when re-cabling occurs). 896 From a data plane perspective, this use case does not require 897 additional data plane extensions. It does only require a protocol 898 extension in the control plane (e.g. this LMP draft) that allows 899 the power control application residing in the DWDM border NE to 900 modify the optical output power of the DWDM domain-external 901 transmitter Tx within the range of the currently used application 902 code. Figure 7 below illustrates this use case utilizing 903 LMP with the extensions identified in this document. 905 Use case 3: Power Control Loop 907 +----------+ +--------------------------+ 908 | +------+ |P(Tx),P(Rx),Set(P(out))| +-------+ +--------+ | 909 | | | | ====================> | | | | Power | | 910 | | LMP | | P(in),P(out),Set(PTx) | | LMP | |Control | | 911 | | | | <==================== | | | | Loop | | 912 | +------+ | | +-------+ +--------+ | 913 | | | | | 914 | +------+ | | P(in) = P(Tx) - a(Tx) | 915 | |C.Loop| | | ___ | 916 | +------+ | | \ / Power Monitor | 917 | | | P(Tx) | V | 918 | +------+ | Ss //\\ | | |\ | 919 | | TX |>----|-----\\//---------------------->| \ | 920 | +------+ | Access Link (AL-T) | . | | | 921 | VOA(Tx) | attenuation a(Tx) | . | |==============> 922 | | | . | | | 923 | External | | --->| / | 924 | Optical | | |/ | 925 |Transpond.| | P(out) | 926 | | | ___ | 927 | | | \ / Power Monitor | 928 | | P(Rx) | V | 929 | +----+ | Rs //\\ | | VOA(out) |\ | 930 | | RX |<---|-----\\//---------------------<|-------| \ | 931 | +----+ | Access Link (AL-R) | . | | | 932 | | attenuation a(Rx) | . | |<======= 933 +----------+ | VOA(out) | | | 934 | <--<|-------| / | 935 P(Rx) = P(out) - a(Rx) | |/ | 936 | | 937 | ROADM | 938 +--------------------------+ 940 Figure 7: Power control loop 942 - The power control loop in transponders and ROADMs controls 943 the Variable Optical Attenuators (VOA) to adjust the proper 944 power in base of the ROADM and Receiver characteristics and 945 the Access Link attenuation 947 6. Requirements 949 Even if network architectures becomes more complex, management and 950 operation as well as the provisioning process should have a higher 951 degree of automation or should be fully automated. Simplifying and 952 automating the entire management and provisioning process of the 953 network in combination with a higher link utilization and faster 954 restoration times will be the major requirements that have been 955 addressed in this section. 957 YANG based network management protocols such as NETCONF [RFC6241] or 958 RESTCONF [RFC8040] are strongly suggested as the base for the 959 communication among EMS, Controller and the Data Plane. 961 Data plane interoperability as defined for example in [ITU-T.G.698.2] 962 is a precondition to take full benefit from standardized interfaces 963 between network and control/management plane. 965 The following requirements are focusing on the usage of DWDM 966 interfaces. 968 1 A procedure to setup an optical connection MUST be defined and 969 implemented in DWDM and client devices (containing the single 970 channel optical interface). The Procedure MAY me defined in a 971 dedicated draft as proposed in Appendix. 973 2 In order to ensure a lean management and provisioning of single 974 channel interfaces, the management and control plane of both the 975 client and DWDM network MUST be aware of the right set of 976 parameters. Such parameters define the interfaces and the optical 977 network and are needed to properly setup the optical connection. 979 3 A standard-based northbound API (to network management system) 980 based on NETCONF/RESTCONF SHOULD be supported, alternatively SNMP 981 MAY be supported too. 983 4 A standard-based data model for single channel interfaces MUST be 984 supported to exchange optical parameters with control/management 985 plane. 987 5 NETCONF SHOULD be used also for configuration of the single 988 channel interfaces including the power setting 990 6 LMP SHOULD be extended and used in cases where optical 991 parameters need to be exchanged between two nodes to correlate 992 link characteristics and adopt the working mode of the single 993 channel interface. The LMP extension MAY be defined in a draft 994 as reported in Appendix. 996 7 LMP MAY be used to adjust the output power of the single 997 channel DWDM interface to ensure that the interface works in 998 the right range. 1000 8 RSVP-TE SHOULD be used to exchange some relevant parameters 1001 between the client and the optical node (e.g. the label value), 1002 without preventing the network to remain in charge of the optical 1003 path computation 1005 9 Power monitoring functions at both ends of the DWDM connection 1006 MAY be used to further automate the setup and shutdown 1007 process of the optical interfaces. 1009 10 In fault cases, the network SHOULD be able to recover wavelengths, 1010 either using pre-defined paths or dynamic re-routing. 1012 11 LMP MAY be used to monitor and observe the access link. 1014 7. Acknowledgements 1016 The authors would like to thank all who supported the work with 1017 fruitful discussions and contributions. 1019 8. IANA Considerations 1021 This memo includes no request to IANA. 1023 9. Security Considerations 1025 The architecture and solution space in scope of this framework 1026 imposes no additional requirements to the security models already 1027 defined in RFC5920 for packet/optical networks using GMPLS, covering 1028 also Control Plane and Management interfaces. Respective security 1029 mechanisms of the components and protocols, e.g. LMP security 1030 models, can be applied unchanged. 1032 As this framework is focusing on the single operator use case, the 1033 security concerns can be relaxed to a subset compared to a setup 1034 where information is exchanged between external parties and over 1035 external interfaces. 1037 Concerning the access control to Management interfaces, security 1038 issues can be generally addressed by authentication techniques 1039 providing origin verification, integrity and confidentiality. 1040 Additionally, access to Management interfaces can be physically or 1041 logically isolated, by configuring them to be only accessible out-of- 1042 band, through a system that is physically or logically separated from 1043 the rest of the network infrastructure. In case where management 1044 interfaces are accessible in-band at the client device or within the 1045 optical transport network domain, filtering or firewalling techniques 1046 can be used to restrict unauthorized in-band traffic. Authentication 1047 techniques may be additionally used in all cases. 1049 10. Contributors 1050 Arnold Mattheus 1051 Deutsche Telekom 1052 Darmstadt 1053 Germany 1054 email arnold.Mattheus@telekom.de 1056 Manuel Paul 1057 Deutsche Telekom 1058 Berlin 1059 Germany 1060 email Manuel.Paul@telekom.de 1062 Josef Roese 1063 Deutsche Telekom 1064 Darmstadt 1065 Germany 1066 email j.roese@telekom.de 1068 Frank Luennemann 1069 Deutsche Telekom 1070 Muenster 1071 Germany 1072 email Frank.Luennemann@telekom.de 1074 Dharini Hiremagalur 1075 Juniper 1076 1133 Innovation Way 1077 Sunnyvale - 94089 California 1078 USA 1079 dharinih@juniper.net 1081 11. References 1083 11.1. Normative References 1085 [ITU-T.G.694.1] 1086 International Telecommunications Union, "Spectral grids 1087 for WDM applications: DWDM frequency grid", 1088 ITU-T Recommendation G.694.1, Febriary 2012. 1090 [ITU-T.G.698.2] 1091 International Telecommunications Union, "Amplified 1092 multichannel dense wavelength division multiplexing 1093 applications with single channel optical interfaces", 1094 ITU-T Recommendation G.698.2, November 2009. 1096 [ITU-T.G.805] 1097 International Telecommunications Union, "Spectral grids 1098 for WDM applications: DWDM frequency grid", 1099 ITU-T Recommendation G.805, March 2000. 1101 [ITU-T.G.872] 1102 International Telecommunications Union, "Architecture of 1103 optical transport networks", ITU-T Recommendation G.872, 1104 November 2001. 1106 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1107 Requirement Levels", BCP 14, RFC 2119, 1108 DOI 10.17487/RFC2119, March 1997, 1109 . 1111 [RFC3591] Lam, H-K., Stewart, M., and A. Huynh, "Definitions of 1112 Managed Objects for the Optical Interface Type", RFC 3591, 1113 DOI 10.17487/RFC3591, September 2003, 1114 . 1116 [RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC 4204, 1117 DOI 10.17487/RFC4204, October 2005, 1118 . 1120 [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, 1121 "Generalized Multiprotocol Label Switching (GMPLS) User- 1122 Network Interface (UNI): Resource ReserVation Protocol- 1123 Traffic Engineering (RSVP-TE) Support for the Overlay 1124 Model", RFC 4208, DOI 10.17487/RFC4208, October 2005, 1125 . 1127 [RFC4209] Fredette, A., Ed. and J. Lang, Ed., "Link Management 1128 Protocol (LMP) for Dense Wavelength Division Multiplexing 1129 (DWDM) Optical Line Systems", RFC 4209, 1130 DOI 10.17487/RFC4209, October 2005, 1131 . 1133 [RFC7689] Bernstein, G., Ed., Xu, S., Lee, Y., Ed., Martinelli, G., 1134 and H. Harai, "Signaling Extensions for Wavelength 1135 Switched Optical Networks", RFC 7689, 1136 DOI 10.17487/RFC7689, November 2015, 1137 . 1139 [RFC7792] Zhang, F., Zhang, X., Farrel, A., Gonzalez de Dios, O., 1140 and D. Ceccarelli, "RSVP-TE Signaling Extensions in 1141 Support of Flexi-Grid Dense Wavelength Division 1142 Multiplexing (DWDM) Networks", RFC 7792, 1143 DOI 10.17487/RFC7792, March 2016, 1144 . 1146 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1147 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1148 May 2017, . 1150 11.2. Informative References 1152 [ITU-T.G.691] 1153 ITU-T, "Optical interfaces for single channel STM-64 and 1154 other SDH systems with optical amplifiers", 1155 ITU-T Recommendation ITU-T G.691, 2008. 1157 [ITU-T.G.693] 1158 ITU-T, "Optical interfaces for intra-office systems", 1159 ITU-T Recommendation ITU-T G.693, 2009. 1161 [ITU-T.G.8081] 1162 ITU-T, "Terms and definitions for Automatically Switched 1163 Optical Networks (ASON)", ITU-T Recommendation G.8081", 1164 ITU-T Recommendation ITU-T G.8081, September 2010. 1166 [ITU-T.G.957] 1167 ITU-T, "Optical interfaces for equipments and systems 1168 relating to the synchronous digital hierarchy", 1169 ITU-T Recommendation ITU-T G.957, 2006. 1171 [Network-Assigned-Upstream-Label] 1172 Internet Engineering Task Force, "Generalized Multi- 1173 Protocol Label Switching (GMPLS) Resource reSerVation 1174 Protocol with Traffic Engineering (RSVP- TE) mechanism 1175 that enables the network to assign an upstream label for a 1176 bidirectional LSP", draft-ietf-teas-network-assigned- 1177 upstream-label draft-ietf-teas-network-assigned-upstream- 1178 label, June 2017. 1180 [RFC5146] Kumaki, K., Ed., "Interworking Requirements to Support 1181 Operation of MPLS-TE over GMPLS Networks", RFC 5146, 1182 DOI 10.17487/RFC5146, March 2008, 1183 . 1185 Appendix A. Appendix 1187 In this section are reported some examples and references on the MIB, 1188 Yang and LMP usage. The MIB and TLV defining the parameters 1189 described above are reported in the drafts below and are intended as 1190 informative data: 1192 draft-dharinigert-ccamp-dwdm-if-lmp 1193 Extension to the Link Management Protocol (LMP/DWDM -rfc4209) for 1194 Dense Wavelength Division Multiplexing (DWDM) Optical Line Systems 1195 to manage the application code of optical interface parameters in 1196 DWDM application 1198 draft-ggalimbe-ccamp-flex-if-lmp 1199 Extension to the Link Management Protocol (LMP/DWDM -rfc4209) for 1200 Dense Wavelength Division Multiplexing (DWDM) Optical Line Systems 1201 to manage the application code of optical interface parameters in 1202 DWDM application 1204 draft-dharini-ccamp-dwdm-if-param-yang 1205 A YANG model to manage the optical interface parameters for an 1206 external transponder in a WDM network 1208 draft-ietf-ccamp-flexigrid-yang 1209 YANG data model for Flexi-Grid Optical Networks 1211 draft-galimbe-ccamp-iv-yang 1212 A YANG model to manage the optical parameters for in a WDM network 1214 NOTE: the above information is defined at the time of publication of 1215 this document and thus subject to change. 1217 Authors' Addresses 1219 Ruediger Kunze (editor) 1220 Deutsche Telekom 1221 Winterfeldtstr. 21-27 1222 10781 Berlin 1223 Germany 1225 Phone: +491702275321 1226 Email: RKunze@telekom.de 1227 Gert Grammel (editor) 1228 Juniper 1229 Oskar-Schlemmer Str. 15 1230 80807 Muenchen 1231 Germany 1233 Phone: +49 1725186386 1234 Email: ggrammel@juniper.net 1236 Dieter Beller 1237 Nokia 1238 Lorenzstrasse, 10 1239 70435 Stuttgart 1240 Germany 1242 Phone: +4971182143125 1243 Email: Dieter.Beller@nokia.com 1245 Gabriele Galimberti (editor) 1246 Cisco 1247 Via S. Maria Molgora, 48c 1248 20871 - Vimercate 1249 Italy 1251 Phone: +390392091462 1252 Email: ggalimbe@cisco.com 1254 Julien Meuric 1255 Orange 1256 2, Avenue Pierre Marzin 1257 22307 Lannion Cedex 1258 France 1260 Phone: +33 1261 Email: julien.meuric@orange.com