idnits 2.17.1 draft-ietf-ccamp-dwdm-if-lmp-04.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 ([ITU-T.G694.1]), 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 date (July 1, 2021) is 1020 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC4902' is mentioned on line 87, but not defined == Missing Reference: 'ITU-T.G959.1' is mentioned on line 303, but not defined == Missing Reference: 'G.694.1' is mentioned on line 312, but not defined == Unused Reference: 'ITU-T.G709' is defined on line 587, but no explicit reference was found in the text == Unused Reference: 'ITU-T.G872' is defined on line 592, but no explicit reference was found in the text == Unused Reference: 'ITU-T.G874.1' is defined on line 597, but no explicit reference was found in the text == Unused Reference: 'RFC4054' is defined on line 603, but no explicit reference was found in the text == Unused Reference: 'RFC2629' is defined on line 625, but no explicit reference was found in the text == Unused Reference: 'RFC3410' is defined on line 629, but no explicit reference was found in the text == Unused Reference: 'RFC4181' is defined on line 635, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU-T.G.698.2' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU-T.G694.1' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU-T.G709' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU-T.G872' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU-T.G874.1' ** Downref: Normative reference to an Informational RFC: RFC 4054 -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) Summary: 2 errors (**), 0 flaws (~~), 11 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force D. Hiremagalur, Ed. 3 Internet-Draft G. Grammel, Ed. 4 Intended status: Standards Track Juniper 5 Expires: January 2, 2022 G. Galimberti, Ed. 6 Cisco 7 R. Kunze, Ed. 8 Deutsche Telekom 9 D. Beller 10 Nokia 11 July 1, 2021 13 Extension to the Link Management Protocol (LMP/DWDM -rfc4209) for Dense 14 Wavelength Division Multiplexing (DWDM) Optical Line Systems to manage 15 the application code of optical interface parameters in DWDM application 16 draft-ietf-ccamp-dwdm-if-lmp-04 18 Abstract 20 This memo defines extensions to LMP(rfc4209) for managing Optical 21 parameters associated with Wavelength Division Multiplexing (WDM) 22 systems in accordance with the Interface Application Identifier 23 approach defined in ITU-T Recommendation G.694.1.[ITU-T.G694.1] and 24 its extensions. 26 Copyright Notice 28 Copyright (c) 2011 IETF Trust and the persons identified as the 29 document authors. All rights reserved. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on January 2, 2022. 48 Copyright Notice 50 Copyright (c) 2021 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. DWDM line system . . . . . . . . . . . . . . . . . . . . . . 3 67 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 3.1. Optical interface parameter collection . . . . . . . . . 4 69 3.2. DWDM client - ROADM interconection discovery . . . . . . 5 70 3.3. Service Setup . . . . . . . . . . . . . . . . . . . . . . 5 71 3.4. Link Monitoring Use Cases . . . . . . . . . . . . . . . . 6 72 4. Extensions to LMP-WDM Protocol . . . . . . . . . . . . . . . 7 73 5. General Parameters - OCh_General . . . . . . . . . . . . . . 7 74 6. ApplicationIdentifier - OCh_ApplicationIdentifier . . . . . . 9 75 7. OCh_Ss - OCh transmit parameters . . . . . . . . . . . . . . 11 76 8. OCh_Rs - receive parameters . . . . . . . . . . . . . . . . . 12 77 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 78 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 79 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13 80 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 81 12.1. Normative References . . . . . . . . . . . . . . . . . . 14 82 12.2. Informative References . . . . . . . . . . . . . . . . . 15 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 85 1. Introduction 87 LMP [RFC4902] provides link property correlation capabilities that 88 can be used between a transceiver device and an Optical Line System 89 (OLS) device. Link property correlation is a procedure by which, 90 intrinsic parameters and capabilities are exchanged between two ends 91 of a link. Link property correlation as defined in RFC3591 allows 92 either end of the link to supervise the received signal and operate 93 within a commonly understood parameter window. Here the term 'link' 94 refers in particular to the attachment link between OXC and OLS (see 95 Figure 1). The relevant interface parameters are in line with 96 "draft-dharini-ccamp-dwdm-if-yang". Use cases are 1- Optical 97 interface parameter collection, 2- DWDM client - ROADM interconection 98 discovery, 3- Service Setup, 4- Service Setup 100 2. DWDM line system 102 Figure 1 shows a set of reference points (Rs and Ss), for a single- 103 channel connection between transmitter (Tx) and receiver (Rx) 104 devices. Here the DWDM network elements in between those devices 105 include an Optical Multiplexer (OM) and an Optical Demultiplexer 106 (OD). In addition it may include one or more Optical Amplifiers (OA) 107 and one or more Optical Add-Drop Multiplexers (OADM). 109 +-------------------------------------------------+ 110 Ss | DWDM Network Elements | Rs 111 +--+ | | | \ / | | | +--+ 112 Tx L1--|->| \ +------+ +------+ / |--|-->Rx L1 113 +---+ | | | | | +------+ | | | | | +--+ 114 +---+ | | | | | | | | | | | | +--+ 115 Tx L2--|->| OM |-->|------|->|ROADM |--|------|->| OD |--|-->Rx L2 116 +---+ | | | | | | | | | | | | +--+ 117 +---+ | | | | | +------+ | | | | | +--+ 118 Tx L3--|->| / | DWDM | | ^ | DWDM | \ |--|-->Rx L3 119 +---+ | | / | Link +----|--|----+ Link | \ | | +--+ 120 +-----------+ | | +----------+ 121 +--+ +--+ 122 | | 123 Rs v | Ss 124 +-----+ +-----+ 125 |RxLx | |TxLx | 126 +-----+ +-----+ 128 Ss = Sender reference point at the DWDM network element 129 tributary output 130 Rs = Receiver reference point at the DWDM network element 131 tributary input 132 Lx = Lambda x 133 OM = Optical Mux 134 OD = Optical Demux 135 ROADM = Reconfigurable Optical Add Drop Mux 137 from Fig. 5.1/G.698.2 139 Figure 1: Linear Single Channel approach 141 Figure 2 Extended LMP Model ( from [RFC4209] ) 143 +------+ Ss +------+ +------+ Rs +------+ 144 | | ----- | | | | ----- | | 145 | OXC1 | ----- | OLS1 | ===== | OLS2 | ----- | OXC2 | 146 | | ----- | | | | ----- | | 147 +------+ +------+ +------+ +------+ 148 ^ ^ ^ ^ ^ ^ 149 | | | | | | 150 | +-----LMP-----+ +-----LMP-----+ | 151 | | 152 +----------------------LMP-----------------------+ 154 OXC : is an entity that contains transponders 155 OLS : generic optical system, it can be - 156 Optical Mux, Optical Demux, Optical Add 157 Drop Mux, Amplifier etc. 158 OLS to OLS : represents the Optical Multiplex section 159 160 Rs/Ss : reference points in between the OXC and the OLS 162 Figure 2: Extended LMP Model 164 3. Use Cases 166 A comparison with the traditional operation scenarios provides an 167 insight of similarities and distinctions in operation and management 168 of DWDM interfaces. The following use cases provide an overview 169 about operation and maintenance processes. 171 3.1. Optical interface parameter collection 173 It is necessary to identify the Optical interface characteristics and 174 setting in order to properly calculate the ent to end path and match 175 the Head End interface against the Tail End interface compatibility. 176 The optical parameters may have multiple possible values that the 177 Controller (SDN or GMPLS) can use and select for the best network 178 optimisation. In case og GMPLS the LMP is suitable to support the 179 parameters exchange between the ROADM and the Transponder (or DWDM 180 interface located into the client box). 182 3.2. DWDM client - ROADM interconection discovery 184 Being the the DWDM port and ROADM port belonging to different domains 185 and Network Elements, the interconnection between them is not 186 embedded in the Optical Nodes and can not be shared to the EMS and 187 the Controller. The Controller needs then to retrieve the 188 connectivity using data coming from the two domains correlating them 189 to discover the relationship. The methods to discover the 190 interconnection can be LMP, LLDP, installation provisioning or any 191 other mechanism checking using the light transmitted by the DWDM 192 transmitter and detecter by the ROAMD port photodiode. This use case 193 is fundamental to build the interconnections between the DWDM and 194 Client layer (e.g. Routers) and calculate the multilayer network 195 topology. 197 3.3. Service Setup 199 It is necessary to differentiate between different operational issues 200 for setting up a light path (a DWDM connection is specific in having 201 defined maximum impairments) within an operational network. 203 The first step is to determine if transceivers located at different 204 end-points are interoperable, i.e. support a common set of 205 operational parameters. In this step it is required to determine 206 transceiver capabilities in a way to be able to correlate them for 207 interoperability purposes. Such parameters include modulation 208 scheme, modulation parameters, FEC to name a few. If both 209 transceivers are controlled by the same NMS or CP, such data is 210 readily available. However in cases where the transceivers are 211 controlled by different CP, a protocol needs to be used to inform the 212 controlling instance (NMS or CP) about transceiver parameters. It is 213 suggested to extend LMP for that purpose. 215 The second step is to determine the feasibility of a lightpath 216 between two transceivers without applying an optical signal. 217 Understanding the limitations of the transceiver pair, a path through 218 the optical network has to be found, whereby each path has an 219 individual set of impairments deteriorating a wavelength traveling 220 along that path. Since a single transceiver can support multiple 221 parameter sets, the selection of a path may limit the permissible 222 parameter sets determined in previous steps. 224 The third step is then to setup the connection itself and to 225 determine the Wavelength. This is done using the NMS of the optical 226 transport network or by means of a control plane interaction such as 227 signaling and includes the path information as well as the parameter 228 set information necessary to enable communication. 230 In a fourth step, optical monitoring is activated in the WDM network 231 in order to monitor the status of the connection. The monitor 232 functions of the optical interfaces at the terminals are also 233 activated in order to monitor the end to end connection. 235 Furthermore it should be possible to automate this step. After 236 connecting the client device to the neighbor control plane-enabled 237 transport node, a control adjacency may be automatically established, 238 e.g. using LMP. 240 3.4. Link Monitoring Use Cases 242 The use cases described below are assuming that power monitoring 243 functions are available in the ingress and egress network element of 244 the DWDM network, respectively. By performing link property 245 correlation it would be beneficial to include the current transmit 246 power value at reference point Ss and the current received power 247 value at reference point Rs. For example if the Client transmitter 248 power has a value of 0dBm and the ROADM interface measured power is 249 -6dBm the fiber patch cord connecting the two nodes may be pinched or 250 the connectors are dirty. As discussed before, the actual path or 251 selection of a specific wavelength within the allowed set is outside 252 the scope of LMP. The computing entities (e.g. the first optical 253 node originating the circuit) can rely on GMPLS IGP (OSPF) to 254 retrieve all the information related to the network, calculate the 255 path to reach the endpoint and signal the path implementation through 256 the network via RSVP-TE. 258 [ITU-T.G.698.2] defines a single channel optical interface for DWDM 259 systems that allows interconnecting network-external optical 260 transponders across a DWDM network. The optical transponders are 261 external to the DWDM network. This so-called 'Black Link' approach 262 illustrated in Fig. 5-1 of [ITU-T.G.698.2]. The single channel fiber 263 link between the Ss/Rs reference points and the ingress/egress port 264 of the network element on the domain boundary of the DWDM network 265 (DWDM border NE) is called access link. Based on the definition in 266 [ITU-T.G.698.2] it is part of the DWDM network. The access link is 267 typically realized as a passive fiber link that has a specific 268 optical attenuation (insertion loss). As the access link is an 269 integral part of the DWDM network, it is desirable to monitor its 270 attenuation. Therefore, it is useful to detect an increase of the 271 access link attenuation, for example, when the access link fiber has 272 been disconnected and reconnected (maintenance) and a bad patch panel 273 connection (connector) resulted in a significantly higher access link 274 attenuation (loss of signal in the extreme case of an open connector 275 or a fiber cut). In the following section, two use cases are 276 presented and discussed: 278 1) pure access link monitoring 279 2) access link monitoring with a power control loop 281 These use cases require a power monitor as described in G.697 (see 282 section 6.1.2), that is capable to measure the optical power of the 283 incoming or outgoing single channel signal. The use case where a 284 power control loop is in place could even be used to compensate an 285 increased attenuation if the optical transmitter can still be 286 operated within its output power range defined by its application 287 code. 289 4. Extensions to LMP-WDM Protocol 291 This document defines extensions to [RFC4209] to allow a set of 292 characteristic parameters, to be exchanged between a router or 293 optical switch (e.g. OTN cross connect) and the optical line system 294 to which it is attached. In particular, this document defines 295 additional Data Link sub-objects to be carried in the LinkSummary 296 message defined in [RFC4204] and [RFC6205]. The OXC and OLS systems 297 may be managed by different Network management systems and hence may 298 not know the capability and status of their peer. These messages and 299 their usage are defined in subsequent sections of this document. 301 The following new messages are defined for the WDM extension for 302 ITU-T G.698.2 [ITU-T.G698.2]/ITU-T G.698.1 [ITU-T.G698.1]/ 303 ITU-T G.959.1 [ITU-T.G959.1] 304 - OCh_General (sub-object Type = TBA) 305 - OCh_ApplicationIdentier (sub-object Type = TBA) 306 - OCh_Ss (sub-object Type = TBA) 307 - OCh_Rs (sub-object Type = TBA) 309 5. General Parameters - OCh_General 311 These are a set of general parameters as described in [G698.2] and 312 [G.694.1]. Please refer to the "draft-dharini-ccamp-dwdm-if-yang" 313 for more details about these parameters and the [RFC6205] for the 314 wavelength definition. 316 The general parameters are 317 1. Central Frequency - (Tera Hz) 4 bytes (see RFC6205 sec.3.2) 318 2. Number of Application Identifiers (A.I.) Supported 319 3. Single-channel Application Identifier in use 320 4. Application Identifier Type in use 321 5. Application Identifier in use 323 Figure 3: The format of the this sub-object (Type = TBA, Length = 324 TBA) is as follows: 326 0 1 2 3 327 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | Type | Length | (Reserved) | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | Central Frequency | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | Number of Application | | 334 | Identifiers Supported | (Reserved) | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | Single-channel| A.I. Type | A.I. length | 337 | Application | in use | | 338 | Identifier | | | 339 | Number in use | | | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | Single-channel Application Identifier in use | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | Single-channel Application Identifier in use | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | Single-channel Application Identifier in use | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 A.I. Type in use: STANDARD, PROPRIETARY 350 A.I. Type in use: STANDARD 352 Refer to G.698.2 recommendation : B-DScW-ytz(v) 354 0 1 2 3 355 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | Single-channel Application Code | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | Single-channel Application Code | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | Single-channel Application Code | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 A.I. Type in use: PROPRIETARY 366 Note: if the A.I. type = PROPRIETARY, the first 6 Octets of the 367 Application Identifier in use are six characters of the 368 PrintableString must contain the Hexadecimal representation of 369 an OUI (Organizationally Unique Identifier) assigned to the 370 vendor whose implementation generated the Application 371 Identifier; the remaining octets of the PrintableString are 372 unspecified. 374 0 1 2 3 375 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | OUI | 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | OUI cont. | Vendor value | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | Vendor Value | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 Figure 3: OCh_General 386 6. ApplicationIdentifier - OCh_ApplicationIdentifier 388 This message is to exchange the application identifiers supported as 389 described in [G698.2]. There can be more than one Application 390 Identifier supported by the transmitter/receiver in the OXC. The 391 number of application identifiers supported is exchanged in the 392 "OCh_General" message. (from [G698.1]/[G698.2]/[G959.1] and G.874.1 393 ) 395 The parameters are 396 1. Number of Application Identifiers (A.I.) Supported 398 2. Single-channel application identifier Number 399 uniquely identifiers this entry - 8 bits 401 3. Application Indentifier Type (A.I.) (STANDARD/PROPRIETARY) 403 4. Single-channel application identifier -- 96 bits 404 (from [G698.1]/[G698.2]/[G959.1] 406 - this parameter can have 407 multiple instances as the transceiver can support multiple 408 application identifiers. 410 Figure 4: The format of the this sub-object (Type = TBA, Length = 411 TBA) is as follows: 413 0 1 2 3 414 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | Type | Length | (Reserved) | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | Number of Application | | 419 | Identifiers Supported | (Reserved) | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | Single-channel| A.I. Type | A.I. length | 422 | Application | | | 423 | Identifier | | | 424 | Number | | | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 | Single-channel Application Identifier | 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 | Single-channel Application Identifier | 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 | Single-channel Application Identifier | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 // .... // 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 | Single-channel| | A.I. length | 435 | Application | A.I. Type | | 436 | Identifier | | | 437 | Number | | | 438 | | | | 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 | Single-channel Application Identifier | 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 | Single-channel Application Identifier | 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 | Single-channel Application Identifier | 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 A.I. Type in use: STANDARD, PROPRIETARY 449 A.I. Type in use: STANDARD 450 Refer to G.698.2 recommendation : B-DScW-ytz(v) 452 0 1 2 3 453 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 | Single-channel Application Code | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 | Single-channel Application Code | 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 | Single-channel Application Code | 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 A.I. Type in use: PROPRIETARY 463 Note: if the A.I. type = PROPRIETARY, the first 6 Octets of the 464 Application Identifier in use are six characters of the 465 PrintableString must contain the Hexadecimal representation of 466 an OUI (Organizationally Unique Identifier) assigned to the 467 vendor whose implementation generated the Application 468 Identifier; the remaining octets of the PrintableString are 469 unspecified. 471 0 1 2 3 472 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 | OUI | 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 | OUI cont. | Vendor value | 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 | Vendor Value | 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 Figure 4: OCh_ApplicationIdentifier 483 7. OCh_Ss - OCh transmit parameters 485 These are the G.698.2 parameters at the Source(Ss reference points). 486 Please refer to "draft-dharini-ccamp-dwdm-if-yang" for more details 487 about these parameters. 489 1. Output power 491 Figure 5: The format of the OCh sub-object (Type = TBA, Length = TBA) 492 is as follows: 494 0 1 2 3 495 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 | Type | Length | (Reserved) | 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 | Output Power | 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 Figure 5: OCh_Ss transmit parameters 504 8. OCh_Rs - receive parameters 506 These are the G.698.2 parameters at the Sink (Rs reference points). 508 1. Current Input Power - (0.1dbm) 4bytes 510 Figure 6: The format of the OCh receive sub-object (Type = TBA, 511 Length = TBA) is as follows: 513 The format of the OCh receive/OLS Sink sub-object (Type = TBA, 514 Length = TBA) is as follows: 516 0 1 2 3 517 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 | Type | Length | (Reserved) | 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 | Current Input Power | 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 Figure 6: OCh_Rs receive parameters 526 9. Security Considerations 528 LMP message security uses IPsec, as described in [RFC4204]. This 529 document only defines new LMP objects that are carried in existing 530 LMP messages, similar to the LMP objects in [RFC:4209]. This 531 document does not introduce new security considerations. 533 10. IANA Considerations 534 LMP defines the following name spaces and 535 the ways in which IANA can make assignments to these namespaces: 537 - LMP Message Type 538 - LMP Object Class 539 - LMP Object Class type (C-Type) unique within the Object Class 540 - LMP Sub-object Class type (Type) unique within the Object Class 541 This memo introduces the following new assignments: 543 LMP Sub-Object Class names: 545 under DATA_LINK Class name (as defined in ) 546 - OCh_General (sub-object Type = TBA) 547 - OCh_ApplicationIdentifier (sub-object Type = TBA) 548 - OCh_Ss (sub-object Type = TBA) 549 - OCh_Rs (sub-object Type = TBA) 551 11. Contributors 553 Arnold Mattheus 554 Deutsche Telekom 555 Darmstadt 556 Germany 557 email a.mattheus@telekom.de 559 John E. Drake 560 Juniper 561 1194 N Mathilda Avenue 562 HW-US,Pennsylvania 563 USA 564 jdrake@juniper.net 566 Zafar Ali 567 Cisco 568 3000 Innovation Drive 569 KANATA 570 ONTARIO K2K 3E8 571 zali@cisco.com 573 12. References 574 12.1. Normative References 576 [ITU-T.G.698.2] 577 International Telecommunications Union, "Amplified 578 multichannel dense wavelength division multiplexing 579 applications with single channel optical interfaces", 580 ITU-T Recommendation G.698.2, November 2009. 582 [ITU-T.G694.1] 583 International Telecommunications Union, ""Spectral grids 584 for WDM applications: DWDM frequency grid"", 585 ITU-T Recommendation G.698.2, February 2012. 587 [ITU-T.G709] 588 International Telecommunications Union, "Interface for the 589 Optical Transport Network (OTN)", ITU-T Recommendation 590 G.709, June 2016. 592 [ITU-T.G872] 593 International Telecommunications Union, "Architecture of 594 optical transport networks", ITU-T Recommendation G.872, 595 January 2017. 597 [ITU-T.G874.1] 598 International Telecommunications Union, "Optical transport 599 network (OTN): Protocol-neutral management information 600 model for the network element view", ITU-T Recommendation 601 G.874.1, November 2016. 603 [RFC4054] Strand, J., Ed. and A. Chiu, Ed., "Impairments and Other 604 Constraints on Optical Layer Routing", RFC 4054, 605 DOI 10.17487/RFC4054, May 2005, 606 . 608 [RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC 4204, 609 DOI 10.17487/RFC4204, October 2005, 610 . 612 [RFC4209] Fredette, A., Ed. and J. Lang, Ed., "Link Management 613 Protocol (LMP) for Dense Wavelength Division Multiplexing 614 (DWDM) Optical Line Systems", RFC 4209, 615 DOI 10.17487/RFC4209, October 2005, 616 . 618 [RFC6205] Otani, T., Ed. and D. Li, Ed., "Generalized Labels for 619 Lambda-Switch-Capable (LSC) Label Switching Routers", 620 RFC 6205, DOI 10.17487/RFC6205, March 2011, 621 . 623 12.2. Informative References 625 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 626 DOI 10.17487/RFC2629, June 1999, 627 . 629 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 630 "Introduction and Applicability Statements for Internet- 631 Standard Management Framework", RFC 3410, 632 DOI 10.17487/RFC3410, December 2002, 633 . 635 [RFC4181] Heard, C., Ed., "Guidelines for Authors and Reviewers of 636 MIB Documents", BCP 111, RFC 4181, DOI 10.17487/RFC4181, 637 September 2005, . 639 Authors' Addresses 641 Dharini Hiremagalur (editor) 642 Juniper 643 1194 N Mathilda Avenue 644 Sunnyvale - 94089 California 645 USA 647 Phone: +1408 648 Email: dharinih@juniper.net 650 Gert Grammel (editor) 651 Juniper 652 Oskar-Schlemmer Str. 15 653 80807 Muenchen 654 Germany 656 Phone: +49 1725186386 657 Email: ggrammel@juniper.net 659 Gabriele Galimberti (editor) 660 Cisco 661 Via S. Maria Molgora, 48 c 662 20871 - Vimercate 663 Italy 665 Phone: +390392091462 666 Email: ggalimbe@cisco.com 667 Ruediger Kunze (editor) 668 Deutsche Telekom 669 Winterfeldtstr. 21-27 670 10781 Berlin 671 Germany 673 Phone: +491702275321 674 Email: RKunze@telekom.de 676 Dieter Beller 677 Nokia 678 Lorenzstrasse, 10 679 70435 Stuttgart 680 Germany 682 Phone: +4971182143125 683 Email: Dieter.Beller@nokia.com