idnits 2.17.1 draft-dharinigert-ccamp-g-698-2-lmp-10.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.G698.2], [ITU.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 6, 2015) is 3210 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: 'ITU.G959.1' is mentioned on line 426, but not defined == Missing Reference: 'G.694.1' is mentioned on line 435, but not defined == Unused Reference: 'RFC4054' is defined on line 709, but no explicit reference was found in the text == Unused Reference: 'ITU.G709' is defined on line 723, but no explicit reference was found in the text == Unused Reference: 'ITU.G872' is defined on line 728, but no explicit reference was found in the text == Unused Reference: 'ITU.G874.1' is defined on line 733, but no explicit reference was found in the text == Unused Reference: 'RFC3410' is defined on line 741, but no explicit reference was found in the text == Unused Reference: 'RFC2629' is defined on line 745, but no explicit reference was found in the text == Unused Reference: 'RFC4181' is defined on line 748, but no explicit reference was found in the text == Unused Reference: 'I-D.kunze-g-698-2-management-control-framework' is defined on line 751, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 4054 -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.G698.2' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.G694.1' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.G709' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.G872' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.G874.1' -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) == Outdated reference: A later version (-02) exists of draft-kunze-g-698-2-management-control-framework-00 Summary: 2 errors (**), 0 flaws (~~), 12 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 7, 2016 G. Galimberti, Ed. 6 Z. Ali, Ed. 7 Cisco 8 R. Kunze, Ed. 9 Deutsche Telekom 10 D. Beller, Ed. 11 ALU 12 July 6, 2015 14 Extension to the Link Management Protocol (LMP/DWDM -rfc4209) for Dense 15 Wavelength Division Multiplexing (DWDM) Optical Line Systems to manage 16 the application code of optical interface parameters in DWDM application 17 draft-dharinigert-ccamp-g-698-2-lmp-10 19 Abstract 21 This memo defines extensions to LMP(rfc4209) for managing Optical 22 parameters associated with Wavelength Division Multiplexing (WDM) 23 systems or characterized by the Optical Transport Network (OTN) in 24 accordance with the Interface Application Code approach defined in 25 ITU-T Recommendation G.698.2.[ITU.G698.2], G.694.1.[ITU.G694.1] and 26 its extensions. 28 Copyright Notice 30 Copyright (c) 2011 IETF Trust and the persons identified as the 31 document authors. All rights reserved. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on January 7, 2016. 50 Copyright Notice 52 Copyright (c) 2015 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 3. Extensions to LMP-WDM Protocol . . . . . . . . . . . . . . . 11 70 4. General Parameters - OCh_General . . . . . . . . . . . . . . 11 71 5. ApplicationIdentifier - OCh_ApplicationIdentifier . . . . . . 13 72 6. OCh_Ss - OCh transmit parameters . . . . . . . . . . . . . . 15 73 7. OCh_Rs - receive parameters . . . . . . . . . . . . . . . . . 15 74 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 75 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 76 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17 77 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 78 11.1. Normative References . . . . . . . . . . . . . . . . . . 17 79 11.2. Informative References . . . . . . . . . . . . . . . . . 18 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 82 1. Introduction 84 This extension is based on "draft-galikunze-ccamp-g-698-2-snmp-mib- 85 10", for the relevant interface optical parameters described in 86 recommendations like ITU-T G.698.2 [ITU.G698.2] and 87 G.694.1.[ITU.G694.1]. The LMP Model from RFC4902 provides link 88 property correlation between a client and an OLS device. LMP link 89 property correlation, exchanges the capabilities of either end of the 90 link where the term 'link' refers to the attachment link between OXC 91 and OLS (see Figure 1). By performing link property correlation, 92 both ends of the link exchange link properties, such as application 93 identifiers. This allows either end to operate within a commonly 94 understood parameter window. Based on known parameter limits, each 95 device can supervise the received signal for conformance using 96 mechanisms defined in RFC3591. For example if the Client transmitter 97 power (OXC1) has a value of 0dBm and the ROADM interface measured 98 power (at OLS1) is -6dBm the fiber patch cord connecting the two 99 nodes may be pinched or the connectors are dirty. More, the 100 interface characteristics can be used by the OLS network Control 101 Plane in order to check the Optical Channels feasibility. Finally 102 the OXC1 transceivers parameters (Application Code) can be shared 103 with OXC2 using the LMP protocol to verify the Transceivers 104 compatibility. The actual route selection of a specific wavelength 105 within the allowed set is outside the scope of LMP. In GMPLS, the 106 parameter selection (e.g. central frequency) is performed by RSVP-TE. 108 Figure 1 shows a set of reference points, for the linear "black link" 109 approach, for single-channel connection (Ss and Rs) between 110 transmitters (Tx) and receivers (Rx). Here the DWDM network elements 111 include an OM and an OD (which are used as a pair with the opposing 112 element), one or more optical amplifiers and may also include one or 113 more OADMs. 115 +-------------------------------------------------+ 116 Ss | DWDM Network Elements | Rs 117 +--+ | | | \ / | | | +--+ 118 Tx L1--|->| \ +------+ +------+ / |--|-->Rx L1 119 +---+ | | | | | +------+ | | | | | +--+ 120 +---+ | | | | | | | | | | | | +--+ 121 Tx L2--|->| OM |-->|------|->| OADM |--|------|->| OD |--|-->Rx L2 122 +---+ | | | | | | | | | | | | +--+ 123 +---+ | | | | | +------+ | | | | | +--+ 124 Tx L3--|->| / | DWDM | | ^ | DWDM | \ |--|-->Rx L3 125 +---+ | | / | Link +----|--|----+ Link | \ | | +--+ 126 +-----------+ | | +----------+ 127 +--+ +--+ 128 | | 129 Rs v | Ss 130 +-----+ +-----+ 131 |RxLx | |TxLx | 132 +-----+ +-----+ 133 Ss = reference point at the DWDM network element tributary output 134 Rs = reference point at the DWDM network element tributary input 135 Lx = Lambda x 136 OM = Optical Mux 137 OD = Optical Demux 138 OADM = Optical Add Drop Mux 140 from Fig. 5.1/G.698.2 142 Figure 1: Linear Black Link approach 144 Figure 2 Extended LMP Model ( from [RFC4209] ) 146 +------+ Ss +------+ +------+ Rs +------+ 147 | | ----- | | | | ----- | | 148 | OXC1 | ----- | OLS1 | ===== | OLS2 | ----- | OXC2 | 149 | | ----- | | | | ----- | | 150 +------+ +------+ +------+ +------+ 151 ^ ^ ^ ^ ^ ^ 152 | | | | | | 153 | +-----LMP-----+ +-----LMP-----+ | 154 | | 155 +----------------------LMP-----------------------+ 157 OXC : is an entity that contains transponders 158 OLS : generic optical system, it can be - 159 Optical Mux, Optical Demux, Optical Add 160 Drop Mux, etc. 161 OLS to OLS : represents the black-Link itself 162 Rs/Ss : in between the OXC and the OLS 164 Figure 2: Extended LMP Model 166 2. Use Cases 168 The use cases described below are assuming that power monitoring 169 functions are available in the ingress and egress network element of 170 the DWDM network, respectively. By performing link property 171 correlation it would be beneficial to include the current transmit 172 power value at reference point Ss and the current received power 173 value at reference point Rs. For example if the Client transmitter 174 power (OXC1) has a value of 0dBm and the ROADM interface measured 175 power (at OLS1) is -6dBm the fiber patch cord connecting the two 176 nodes may be pinched or the connectors are dirty. More, the 177 interface characteristics can be used by the OLS network Control 178 Plane in order to check the Optical Channels feasibility. Finally 179 the OXC1 transceivers parameters (Application Code) can be shared 180 with OXC2 using the LMP protocol to verify the Transceivers 181 compatibility. The actual route selection of a specific wavelength 182 within the allowed set is outside the scope of LMP. In GMPLS, the 183 parameter selection (e.g. central frequency) is performed by RSVP-TE. 185 G.698.2 defines a single channel optical interface for DWDM systems 186 that allows interconnecting network-external optical transponders 187 across a DWDM network. The optical transponders are considered to be 188 external to the DWDM network. This so-called 'black link' approach 189 illustrated in Figure 5-1 of G.698.2 and a copy of this figure is 190 provided below. The single channel fiber link between the Ss/Rs 191 reference points and the ingress/egress port of the network element 192 on the domain boundary of the DWDM network (DWDM border NE) is called 193 access link in this contribution. Based on the definition in G.698.2 194 it is considered to be part of the DWDM network. The access link 195 typically is realized as a passive fiber link that has a specific 196 optical attenuation (insertion loss). As the access link is an 197 integral part of the DWDM network, it is desirable to monitor its 198 attenuation. Therefore, it is useful to detect an increase of the 199 access link attenuation, for example, when the access link fiber has 200 been disconnected and reconnected (maintenance) and a bad patch panel 201 connection (connector) resulted in a significantly higher access link 202 attenuation (loss of signal in the extreme case of an open connector 203 or a fiber cut). In the following section, two use cases are 204 presented and discussed: 206 1) pure access link monitoring 207 2) access link monitoring with a power control loop 209 These use cases require a power monitor as described in G.697 (see 210 section 6.1.2), that is capable to measure the optical power of the 211 incoming or outgoing single channel signal. The use case where a 212 power control loop is in place could even be used to compensate an 213 increased attenuation as long as the optical transmitter can still be 214 operated within its output power range defined by its application 215 code. 217 Figure 3 Access Link Power Monitoring 219 +--------------------------+ 220 | P(in) = P(Tx) - a(Tx) | 221 | ___ | 222 +----------+ | \ / Power Monitor | 223 | | P(Tx) | V P(in) | 224 | +----+ | Ss //\\ | | |\ | 225 | | TX |----|-----\\//------------------->| \ | 226 | +----+ | Access Link (AL-T) | . | | | 227 | | attenuation a(Tx) | . | |==============> 228 | | | . | | | 229 | External | | --->| / | 230 | Optical | | |/ | 231 |Transpond.| | P(out) | 232 | | | ___ | 233 | | | \ / Power Monitor | 234 | | P(Rx) | V P(out) | 235 | +----+ | Rs //\\ | | |\ | 236 | | RX |<---|-----\\//--------------------| \ | 237 | +----+ | Access Link (AL-R) | . | | | 238 | | Attenuation a(Rx) | . | |<============== 239 +----------+ | . | | | 240 | <---| / | 241 P(Rx) = P(out) - a(Rx) | |/ | 242 | | 243 | ROADM | 244 +--------------------------+ 246 - For AL-T monitoring: P(Tx) and a(Tx) must be known 247 - For AL-R monitoring: P(RX) and a(Rx) must be known 249 An alarm shall be raised if P(in) or P(Rx) drops below a 250 configured threshold (t [dB]): 251 - P(in) < P(Tx) - a(Tx) - t (Tx direction) 252 - P(Rx) < P(out) - a(Rx) - t (Rx direction) 253 - a(Tx) =| a(Rx) 255 Figure 3: Extended LMP Model 257 Pure Access Link (AL) Monitoring Use Case 259 Figure 4 illustrates the access link monitoring use case and the 260 different physical properties involved that are defined below: 262 - Ss, Rs: G.698.2 reference points 263 - P(Tx): current optical output power of transmitter Tx 264 - a(Tx): access link attenuation in Tx direction (external 265 transponder point of view) 266 - P(in): measured current optical input power at the input port 267 of border DWDM NE 268 - t: user defined threshold (tolerance) 269 - P(out): measured current optical output power at the output port 270 of border DWDM NE 271 - a(Rx): access link attenuation in Rx direction (external 272 transponder point of view) 273 - P(Rx): current optical input power of receiver Rx 275 Assumptions: 276 - The access link attenuation in both directions (a(Tx), a(Rx)) 277 is known or can be determined as part of the commissioning 278 process. Typically, both values are the same. 279 - A threshold value t has been configured by the operator. This 280 should also be done during commissioning. 281 - A control plane protocol (e.g. this draft) is in place that allows 282 to periodically send the optical power values P(Tx) and P(Rx) 283 to the control plane protocol instance on the DWDM border NE. 284 This is llustrated in Figure 3. 285 - The DWDM border NE is capable to periodically measure the optical 286 power Pin and Pout as defined in G.697 by power monitoring points 287 depicted as yellow triangles in the figures below. 289 AL monitoring process: 290 - Tx direction: the measured optical input power Pin is compared 291 with the expected optical input power P(Tx) - a(Tx). If the 292 measured optical input power P(in) drops below the value 293 (P(Tx) - a(Tx) - t) a low power alarm shall be raised indicating 294 that the access link attenuation has exceeded a(Tx) + t. 295 - Rx direction: the measured optical input power P(Rx) is 296 compared with the expected optical input power P(out) - a(Rx). 297 If the measured optical input power P(Rx) drops below the value 298 (P(out) - a(Rx) - t) a 299 low power alarm shall be raised indicating that the access link 300 attenuation has exceeded a(Rx) + t. 302 Figure 4 Use case 1: Access Link power monitoring 304 +----------+ +--------------------------+ 305 | +------+ | P(Tx), P(Rx) | +-------+ | 306 | | | | =================> | | | | 307 | | LMP | | P(in), P(out) | | LMP | | 308 | | | | <================= | | | | 309 | +------+ | | +-------+ | 310 | | | | 311 | | | P(in) - P(Tx) - a(Tx) | 312 | | | ___ | 313 | | | \ / Power Monitor | 314 | | P(Tx) | V | 315 | +----+ | Ss //\\ | | |\ | 316 | | TX |----|-----\\//------------------->| \ | 317 | +----+ | Access Link (AL-T) | . | | | 318 | | attenuation a(Tx) | . | |==============> 319 | | | . | | | 320 | External | | --->| / | 321 | Optical | | |/ | 322 |Transpond.| | P(out) | 323 | | | ___ | 324 | | | \ / Power Monitor | 325 | | P(Rx) | V | 326 | +----+ | Rs //\\ | | |\ | 327 | | RX |<---|-----\\//--------------------| \ | 328 | +----+ | Access Link (AL-R) | . | | | 329 | | Attenuation a(Rx) | . | |<============== 330 +----------+ | . | | | 331 | <---| / | 332 P(Rx) = P(out) - a(Rx) | |/ | 333 | | 334 | ROADM | 335 +--------------------------+ 337 - For AL-T monitoring: P(Tx) and a(Tx) must be known 338 - For AL-R monitoring: P(RX) and a(Rx) must be known 339 An alarm shall be raised if P(in) or P(Rx) drops below a 340 configured threshold (t [dB]): 341 - P(in) < P(Tx) - a(Tx) - t (Tx direction) 342 - P(Rx) < P(out) - a(Rx) - t (Rx direction) 343 - a(Tx) = a(Rx) 345 Figure 4: Extended LMP Model 347 Power Control Loop Use Case 349 This use case is based on the access link monitoring use case as 350 described above. In addition, the border NE is running a power 351 control application that is capable to control the optical output 352 power of the single channel tributary signal at the output port 353 of the border DWDM NE (towards the external receiver Rx) and the 354 optical output power of the single channel tributary signal at 355 the external transmitter Tx within their known operating range. 356 The time scale of this control loop is typically relatively slow 357 (e.g. some 10s or minutes) because the access link attenuation 358 is not expected to vary much over time (the attenuation only 359 changes when re-cabling occurs). 360 From a data plane perspective, this use case does not require 361 additional data plane extensions. It does only require a protocol 362 extension in the control plane (e.g. this LMP draft) that allows 363 the power control application residing in the DWDM border NE to 364 modify the optical output power of the DWDM domain-external 365 transmitter Tx within the range of the currently used application 366 code. Figure 5 below illustrates this use case utilizing the LMP 367 protocol with extensions defined in this draft. 369 Figure 5 Use case 2: Power Control Loop 371 +----------+ +--------------------------+ 372 | +------+ | P(Tx),P(Rx),Set(Pout) | +-------+ +--------+ | 373 | | | | ====================> | | | | Power | | 374 | | LMP | | P(in),P(out),Set(PTx) | | LMP | |Control | | 375 | | | | <==================== | | | | Loop | | 376 | +------+ | | +-------+ +--------+ | 377 | | | | | 378 | +------+ | | P(in) = P(Tx) - a(Tx) | 379 | |C.Loop| | | ___ | 380 | +------+ | | \ / Power Monitor | 381 | | | P(Tx) | V | 382 | +------+ | Ss //\\ | | |\ | 383 | | TX |>----|-----\\//---------------------->| \ | 384 | +------+ | Access Link (AL-T) | . | | | 385 | VOA(Tx) | attenuation a(Tx) | . | |==============> 386 | | | . | | | 387 | External | | --->| / | 388 | Optical | | |/ | 389 |Transpond.| | P(out) | 390 | | | ___ | 391 | | | \ / Power Monitor | 392 | | P(Rx) | V | 393 | +----+ | Rs //\\ | | VOA(out) |\ | 394 | | RX |<---|-----\\//---------------------<|-------| \ | 395 | +----+ | Access Link (AL-R) | . | | | 396 | | attenuation a(Rx) | . | |<======= 397 +----------+ | VOA(out) | | | 398 | <--<|-------| / | 399 P(Rx) = P(out) - a(Rx) | |/ | 400 | | 401 | ROADM | 402 +--------------------------+ 404 - The Power Control Loops in Transponder and ROADM regulate 405 the Variable Optical Attenuators (VOA) to adjust the proper 406 power in base of the ROADM and Receiver caracteristics and 407 the Access Link attenuation 409 Figure 5: Extended LMP Model 411 3. Extensions to LMP-WDM Protocol 413 This document defines extensions to [RFC4209] to allow the Black Link 414 (BL) parameters of G.698.2, to be exchanged between a router or 415 optical switch and the optical line system to which it is attached. 416 In particular, this document defines additional Data Link sub-objects 417 to be carried in the LinkSummary message defined in [RFC4204] and 418 [RFC6205]. The OXC and OLS systems may be managed by different 419 Network management systems and hence may not know the capability and 420 status of their peer. The intent of this draft is to enable the OXC 421 and OLS systems to exchange this information. These messages and 422 their usage are defined in subsequent sections of this document. 424 The following new messages are defined for the WDM extension for 425 ITU-T G.698.2 [ITU.G698.2]/ITU-T G.698.1 [ITU.G698.1]/ 426 ITU-T G.959.1 [ITU.G959.1] 427 - OCh_General (sub-object Type = TBA) 428 - OCh_ApplicationIdentier (sub-object Type = TBA) 429 - OCh_Ss (sub-object Type = TBA) 430 - OCh_Rs (sub-object Type = TBA) 432 4. General Parameters - OCh_General 434 These are the general parameters as described in [G698.2] and 435 [G.694.1]. Please refer to the "draft-galikunze-ccamp-g-698-2-snmp- 436 mib-12" for more details about these parameters and the [RFC6205] for 437 the wavelength definition. 439 The general parameters are 440 1. Central Frequency - (Tera Hz) 4 bytes (see RFC6205 sec.3.2) 441 2. Number of Application Identifiers (A.I.) Supported 442 3. Single-channel Application Identifier in use 443 4. Application Identifier Type in use 444 5. Application Identifier in use 446 Figure 6: The format of the this sub-object (Type = TBA, Length = 447 TBA) is as follows: 449 0 1 2 3 450 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 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | Type | Length | (Reserved) | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | Central Frequency | 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 | Number of Application | | 457 | Identifiers Supported | (Reserved) | 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 | Single-channel| A.I. Type | A.I. length | 460 | Application | in use | | 461 | Identifier | | | 462 | Number in use | | | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 | Single-channel Application Identifier in use | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | Single-channel Application Identifier in use | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 | Single-channel Application Identifier in use | 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 A.I. Type in use: STANDARD, PROPRIETARY 473 A.I. Type in use: STANDARD 475 Refer to G.698.2 recommendation : B-DScW-ytz(v) 477 0 1 2 3 478 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 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | Single-channel Application Code | 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 | Single-channel Application Code | 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 | Single-channel Application Code | 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 A.I. Type in use: PROPRIETARY 489 Note: if the A.I. type = PROPRIETARY, the first 6 Octets of the 490 Application Identifier in use are six characters of the 491 PrintableString must contain the Hexadecimal representation of 492 an OUI (Organizationally Unique Identifier) assigned to the 493 vendor whose implementation generated the Application 494 Identifier; the remaining octets of the PrintableString are 495 unspecified. 497 0 1 2 3 498 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 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 | OUI | 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 | OUI cont. | Vendor value | 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 | Vendor Value | 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 Figure 6: OCh_General 509 5. ApplicationIdentifier - OCh_ApplicationIdentifier 511 This message is to exchange the application identifiers supported as 512 described in [G698.2]. Please refer to the "draft-galikunze-ccamp- 513 g-698-2-snmp-mib-10". For more details about these parameters. 514 There can be more than one Application Identifier supported by the 515 OXC/OLS. The number of application identifiers supported is 516 exchanged in the "OCh_General" message. (from 517 [G698.1]/[G698.2]/[G959.1] and G.874.1 ) 519 The parameters are 520 1. Number of Application Identifiers (A.I.) Supported 522 2. Single-channel application identifier Number 523 uniquely identifiers this entry - 8 bits 525 3. Application Indentifier Type (A.I.) (STANDARD/PROPRIETARY) 527 4. Single-channel application identifier -- 96 bits 528 (from [G698.1]/[G698.2]/[G959.1] 530 - this parameter can have 531 multiple instances as the transceiver can support multiple 532 application identifiers. 534 Figure 7: The format of the this sub-object (Type = TBA, Length = 535 TBA) is as follows: 537 0 1 2 3 538 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 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 | Type | Length | (Reserved) | 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 | Number of Application | | 543 | Identifiers Supported | (Reserved) | 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 | Single-channel| A.I. Type | A.I. length | 546 | Application | | | 547 | Identifier | | | 548 | Number | | | 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 | Single-channel Application Identifier | 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 | Single-channel Application Identifier | 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 | Single-channel Application Identifier | 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 // .... // 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 | Single-channel| | A.I. length | 559 | Application | A.I. Type | | 560 | Identifier | | | 561 | Number | | | 562 | | | | 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 | Single-channel Application Identifier | 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 | Single-channel Application Identifier | 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 | Single-channel Application Identifier | 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 A.I. Type in use: STANDARD, PROPRIETARY 573 A.I. Type in use: STANDARD 574 Refer to G.698.2 recommendation : B-DScW-ytz(v) 576 0 1 2 3 577 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 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 | Single-channel Application Code | 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 581 | Single-channel Application Code | 582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 | Single-channel Application Code | 584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 A.I. Type in use: PROPRIETARY 588 Note: if the A.I. type = PROPRIETARY, the first 6 Octets of the 589 Application Identifier in use are six characters of the 590 PrintableString must contain the Hexadecimal representation of 591 an OUI (Organizationally Unique Identifier) assigned to the 592 vendor whose implementation generated the Application 593 Identifier; the remaining octets of the PrintableString are 594 unspecified. 596 0 1 2 3 597 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 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 | OUI | 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 | OUI cont. | Vendor value | 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 | Vendor Value | 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 Figure 7: OCh_ApplicationIdentifier 608 6. OCh_Ss - OCh transmit parameters 610 These are the G.698.2 parameters at the Source(Ss reference points). 611 Please refer to "draft-galikunze-ccamp-g-698-2-snmp-mib-10" for more 612 details about these parameters. 614 1. Output power 616 Figure 8: The format of the OCh sub-object (Type = TBA, Length = TBA) 617 is as follows: 619 0 1 2 3 620 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 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 | Type | Length | (Reserved) | 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 | Output Power | 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 Figure 8: OCh_Ss transmit parameters 629 7. OCh_Rs - receive parameters 631 These are the G.698.2 parameters at the Sink (Rs reference points). 632 Please refer to the "draft-galikunze-ccamp-g-698-2-snmp-mib-10" for 633 more details about these parameters. 635 1. Current Input Power - (0.1dbm) 4bytes 637 Figure 9: The format of the OCh receive sub-object (Type = TBA, 638 Length = TBA) is as follows: 640 The format of the OCh receive/OLS Sink sub-object (Type = TBA, 641 Length = TBA) is as follows: 643 0 1 2 3 644 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 645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 646 | Type | Length | (Reserved) | 647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 648 | Current Input Power | 649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 Figure 9: OCh_Rs receive parameters 653 8. Security Considerations 655 LMP message security uses IPsec, as described in [RFC4204]. This 656 document only defines new LMP objects that are carried in existing 657 LMP messages, similar to the LMP objects in [RFC:4209]. This 658 document does not introduce new security considerations. 660 9. IANA Considerations 662 LMP defines the following name spaces and 663 the ways in which IANA can make assignments to these namespaces: 665 - LMP Message Type 666 - LMP Object Class 667 - LMP Object Class type (C-Type) unique within the Object Class 668 - LMP Sub-object Class type (Type) unique within the Object Class 669 This memo introduces the following new assignments: 671 LMP Sub-Object Class names: 673 under DATA_LINK Class name (as defined in ) 674 - OCh_General (sub-object Type = TBA) 675 - OCh_ApplicationIdentifier (sub-object Type = TBA) 676 - OCh_Ss (sub-object Type = TBA) 677 - OCh_Rs (sub-object Type = TBA) 679 10. Contributors 681 Arnold Mattheus 682 Deutsche Telekom 683 Darmstadt 684 Germany 685 email a.mattheus@telekom.de 687 John E. Drake 688 Juniper 689 1194 N Mathilda Avenue 690 HW-US,Pennsylvania 691 USA 692 jdrake@juniper.net 694 11. References 696 11.1. Normative References 698 [RFC4204] Lang, J., "Link Management Protocol (LMP)", RFC 4204, 699 October 2005. 701 [RFC4209] Fredette, A. and J. Lang, "Link Management Protocol (LMP) 702 for Dense Wavelength Division Multiplexing (DWDM) Optical 703 Line Systems", RFC 4209, October 2005. 705 [RFC6205] Otani, T. and D. Li, "Generalized Labels for Lambda- 706 Switch-Capable (LSC) Label Switching Routers", RFC 6205, 707 March 2011. 709 [RFC4054] Strand, J. and A. Chiu, "Impairments and Other Constraints 710 on Optical Layer Routing", RFC 4054, May 2005. 712 [ITU.G698.2] 713 International Telecommunications Union, "Amplified 714 multichannel dense wavelength division multiplexing 715 applications with single channel optical interfaces", 716 ITU-T Recommendation G.698.2, November 2009. 718 [ITU.G694.1] 719 International Telecommunications Union, ""Spectral grids 720 for WDM applications: DWDM frequency grid"", ITU-T 721 Recommendation G.698.2, February 2012. 723 [ITU.G709] 724 International Telecommunications Union, "Interface for the 725 Optical Transport Network (OTN)", ITU-T Recommendation 726 G.709, February 2012. 728 [ITU.G872] 729 International Telecommunications Union, "Architecture of 730 optical transport networks", ITU-T Recommendation G.872, 731 October 2012. 733 [ITU.G874.1] 734 International Telecommunications Union, "Optical transport 735 network (OTN): Protocol-neutral management information 736 model for the network element view", ITU-T Recommendation 737 G.874.1, October 2012. 739 11.2. Informative References 741 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 742 "Introduction and Applicability Statements for Internet- 743 Standard Management Framework", RFC 3410, December 2002. 745 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 746 June 1999. 748 [RFC4181] Heard, C., "Guidelines for Authors and Reviewers of MIB 749 Documents", BCP 111, RFC 4181, September 2005. 751 [I-D.kunze-g-698-2-management-control-framework] 752 Kunze, R., "A framework for Management and Control of 753 optical interfaces supporting G.698.2", draft-kunze- 754 g-698-2-management-control-framework-00 (work in 755 progress), July 2011. 757 Authors' Addresses 759 Dharini Hiremagalur (editor) 760 Juniper 761 1194 N Mathilda Avenue 762 Sunnyvale - 94089 California 763 USA 765 Phone: +1408 766 Email: dharinih@juniper.net 767 Gert Grammel (editor) 768 Juniper 769 Oskar-Schlemmer Str. 15 770 80807 Muenchen 771 Germany 773 Phone: +49 1725186386 774 Email: ggrammel@juniper.net 776 Gabriele Galimberti (editor) 777 Cisco 778 Via S. Maria Molgora, 48 779 20871 - Vimercate 780 Italy 782 Phone: +390392091462 783 Email: ggalimbe@cisco.com 785 Zafar Ali (editor) 786 Cisco 787 3000 Innovation Drive 788 KANATA 789 ONTARIO K2K 3E8 791 Email: zali@cisco.com 793 Ruediger Kunze (editor) 794 Deutsche Telekom 795 Dddd, xx 796 Berlin 797 Germany 799 Phone: +49xxxxxxxxxx 800 Email: RKunze@telekom.de 802 Dieter Beller (editor) 803 ALU 804 Lorenzstrasse, 10 805 70435 Stuttgart 806 Germany 808 Phone: +4971182143125 809 Email: Dieter.Beller@alcatel-lucent.com