idnits 2.17.1 draft-galikunze-ccamp-g-698-2-snmp-mib-12.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.G874.1], [ITU.G698.2]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (July 6, 2015) is 3216 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-T G.7710' is mentioned on line 134, but not defined == Missing Reference: 'TEMPLATE TODO' is mentioned on line 1038, but not defined == Unused Reference: 'RFC6205' is defined on line 1179, but no explicit reference was found in the text == Unused Reference: 'ITU.G709' is defined on line 1189, but no explicit reference was found in the text == Unused Reference: 'ITU.G959.1' is defined on line 1216, but no explicit reference was found in the text == Unused Reference: 'ITU.G826' is defined on line 1221, but no explicit reference was found in the text == Unused Reference: 'ITU.G8201' is defined on line 1227, but no explicit reference was found in the text == Unused Reference: 'ITU.G7710' is defined on line 1238, but no explicit reference was found in the text == Unused Reference: 'RFC2629' is defined on line 1249, but no explicit reference was found in the text == Unused Reference: 'RFC4181' is defined on line 1252, but no explicit reference was found in the text == Unused Reference: 'I-D.kunze-g-698-2-management-control-framework' is defined on line 1255, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.G698.2' -- 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.G798' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.G874' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.G874.1' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.G959.1' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.G826' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.G8201' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.G694.1' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.G7710' -- 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: 1 error (**), 0 flaws (~~), 14 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force G.Galimberti, Ed. 3 Internet-Draft Cisco 4 Intended status: Standards Track R.Kunze, Ed. 5 Expires: January 7, 2016 Deutsche Telekom 6 Kam Lam, Ed. 7 Alcatel-Lucent 8 D. Hiremagalur, Ed. 9 Juniper 10 L.Fang, Ed. 11 G.Ratterree, Ed. 12 Microsoft 13 July 6, 2015 15 An SNMP MIB extension to RFC3591 to manage optical interface parameters 16 of "G.698.2 single channel" in DWDM applications 17 draft-galikunze-ccamp-g-698-2-snmp-mib-12 19 Abstract 21 This memo defines a module of the Management Information Base (MIB) 22 used by Simple Network Management Protocol (SNMP) in TCP/IP- based 23 internet. In particular, it defines objects for managing single 24 channel optical interface parameters of DWDM applications, using the 25 approach specified in G.698.2 [ITU.G698.2] . This interface, 26 described in ITU-T G.872, G.709 and G.798, is one type of OTN multi- 27 vendor Intra-Domain Interface (IaDI). This RFC is an extension of 28 RFC3591 to support the optical parameters specified in ITU-T G.698.2 29 and application identifiers specified in ITU-T G.874.1 [ITU.G874.1]. 30 Note that G.874.1 encompasses vendor-specific codes, which if used 31 would make the interface a single vendor IaDI and could still be 32 managed. 34 The MIB module defined in this memo can be used for Optical 35 Parameters monitoring and/or configuration of the endpoints of the 36 multi-vendor IaDI based on the Black Link approach. 38 Copyright Notice 40 Copyright (c) 2015 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 Status of This Memo 45 This Internet-Draft is submitted in full conformance with the 46 provisions of BCP 78 and BCP 79. 48 Internet-Drafts are working documents of the Internet Engineering 49 Task Force (IETF). Note that other groups may also distribute 50 working documents as Internet-Drafts. The list of current Internet- 51 Drafts is at http://datatracker.ietf.org/drafts/current/. 53 Internet-Drafts are draft documents valid for a maximum of six months 54 and may be updated, replaced, or obsoleted by other documents at any 55 time. It is inappropriate to use Internet-Drafts as reference 56 material or to cite them other than as "work in progress." 58 This Internet-Draft will expire on January 7, 2016. 60 Copyright Notice 62 Copyright (c) 2015 IETF Trust and the persons identified as the 63 document authors. All rights reserved. 65 This document is subject to BCP 78 and the IETF Trust's Legal 66 Provisions Relating to IETF Documents 67 (http://trustee.ietf.org/license-info) in effect on the date of 68 publication of this document. Please review these documents 69 carefully, as they describe your rights and restrictions with respect 70 to this document. Code Components extracted from this document must 71 include Simplified BSD License text as described in Section 4.e of 72 the Trust Legal Provisions and are provided without warranty as 73 described in the Simplified BSD License. 75 Table of Contents 77 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 78 2. The Internet-Standard Management Framework . . . . . . . . . 4 79 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5 80 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 81 4.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 6 82 4.2. Optical Parameters Description . . . . . . . . . . . . . 13 83 4.2.1. Rs-Ss Configuration . . . . . . . . . . . . . . . . . 13 84 4.2.2. Table of Application Identifiers . . . . . . . . . . 14 85 4.3. Use of ifTable . . . . . . . . . . . . . . . . . . . . . 15 86 4.3.1. Use of ifTable for OPS Layer . . . . . . . . . . . . 16 87 4.3.2. Use of ifTable for OCh Layer . . . . . . . . . . . . 17 88 4.3.3. Use of ifStackTable . . . . . . . . . . . . . . . . . 17 89 5. Structure of the MIB Module . . . . . . . . . . . . . . . . . 18 90 6. Object Definitions . . . . . . . . . . . . . . . . . . . . . 18 91 7. Relationship to Other MIB Modules . . . . . . . . . . . . . . 25 92 7.1. Relationship to the [TEMPLATE TODO] MIB . . . . . . . . . 25 93 7.2. MIB modules required for IMPORTS . . . . . . . . . . . . 25 94 8. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 25 95 9. Security Considerations . . . . . . . . . . . . . . . . . . . 25 96 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 97 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 26 98 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 99 12.1. Normative References . . . . . . . . . . . . . . . . . . 27 100 12.2. Informative References . . . . . . . . . . . . . . . . . 29 101 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 30 102 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 30 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 105 1. Introduction 107 This memo defines a portion of the Management Information Base (MIB) 108 used by Simple Network Management Protocol (SNMP)in TCP/IP-based 109 internets. In particular, it defines objects for managing single 110 channel optical interface parameters of DWDM applications, using the 111 approach specified in G.698.2. This RFC is an extension of RFC3591 112 to support the optical parameters specified in ITU-T G.698.2 113 [ITU.G698.2] and application identifiers specified in ITU-T G.874.1 114 [ITU.G874.1] . Note that G.874.1 encompasses vendor-specific codes, 115 which if used would make the interface a single vendor IaDI and could 116 still be managed. 118 The Black Link approach allows supporting an optical transmitter/ 119 receiver pair of one vendor to inject an optical tributary signal and 120 run it over an optical network composed of amplifiers, filters, add- 121 drop multiplexers from a different vendor. In the OTN architecture, 122 the 'black-link' represents a pre-certified network media channel 123 conforming to G.698.2 specifications at the S and R reference points. 125 [Editor's note: In G.698.2 this corresponds to the optical path from 126 point S to R; network media channel is also used and explained in 127 draft-ietf-ccamp-flexi-grid-fwk-02] 129 Management will be performed at the edges of the network media 130 channel (i.e., at the transmitters and receivers attached to the S 131 and R reference points respectively) for the relevant parameters 132 specified in G.698.2 [ITU.G698.2], G.798 [ITU.G798], G.874 133 [ITU.G874], and the performance parameters specified in G.7710/Y.1701 134 [ITU-T G.7710] and G.874.1 [ITU.G874.1]. 136 G.698.2 [ITU.G698.2] is primarily intended for metro applications 137 that include optical amplifiers. Applications are defined in G.698.2 138 [ITU.G698.2] using optical interface parameters at the single-channel 139 connection points between optical transmitters and the optical 140 multiplexer, as well as between optical receivers and the optical 141 demultiplexer in the DWDM system. This Recommendation uses a 142 methodology which does not explicitly specify the details of the 143 optical network between reference point Ss and Rs, e.g., the passive 144 and active elements or details of the design. The Recommendation 145 currently includes unidirectional DWDM applications at 2.5 and 10 146 Gbit/s (with 100 GHz and 50 GHz channel frequency spacing). Work is 147 still under way for 40 and 100 Gbit/s interfaces. There is 148 possibility for extensions to a lower channel frequency spacing. 149 This document specifically refers to the "application code" defined 150 in the G.698.2 [ITU.G698.2] and included in the Application 151 Identifier defined in G.874.1 [ITU.G874.1] and G.872 [ITU.G872], plus 152 a few optical parameters not included in the G.698.2 application code 153 specification. 155 This draft refers and supports also the draft-kunze-g-698-2- 156 management-control-framework 158 The building of an SNMP MIB describing the optical parameters defined 159 in G.698.2 [ITU.G698.2], and reflected in G.874.1 [ITU.G874], allows 160 the different vendors and operator to retrieve, provision and 161 exchange information across the G.698.2 multi-vendor IaDI in a 162 standardized way. 164 The MIB, reporting the Optical parameters and their values, 165 characterizes the features and the performances of the optical 166 components and allow a reliable black link design in case of multi 167 vendor optical networks. 169 Although RFC 3591 [RFC3591] describes and defines the SNMP MIB of a 170 number of key optical parameters, alarms and Performance Monitoring, 171 as this RFC is over a decade old, it is primarily pre-OTN, and a more 172 complete and up-to-date description of optical parameters and 173 processes can be found in the relevant ITU-T Recommendations. The 174 same considerations can be applied to the RFC 4054 [RFC4054] 176 2. The Internet-Standard Management Framework 178 For a detailed overview of the documents that describe the current 179 Internet-Standard Management Framework, please refer to section 7 of 180 RFC 3410 [RFC3410]. 182 Managed objects are accessed via a virtual information store, termed 183 the Management Information Base or MIB. MIB objects are generally 184 accessed through the Simple Network Management Protocol (SNMP). 185 Objects in the MIB are defined using the mechanisms defined in the 186 Structure of Management Information (SMI). This memo specifies a MIB 187 module that is compliant to the SMIv2, which is described in STD 58, 188 RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 189 [RFC2580]. 191 3. Conventions 193 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 194 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 195 document are to be interpreted as described in RFC 2119 [RFC2119] In 196 the description of OIDs the convention: Set (S) Get (G) and Trap (T) 197 conventions will describe the action allowed by the parameter. 199 4. Overview 201 Figure 1 shows a set of reference points, for the linear "black link" 202 approach, for single-channel connection (Ss and Rs) between 203 transmitters (Tx) and receivers (Rx). Here the DWDM network elements 204 include an OM and an OD (which are used as a pair with the opposing 205 element), one or more optical amplifiers and may also include one or 206 more OADMs. 208 +-------------------------------------------------+ 209 Ss | DWDM Network Elements | Rs 210 +---+ | | | \ / | | | +--+ 211 Tx L1----|->| \ +------+ +------+ / |--|-->Rx L1 212 +---+ | | | | | +------+ | | | | | +--+ 213 +---+ | | | | | | | | | | | | +--+ 214 Tx L2----|->| OM |-->|------|->| OADM |--|------|->| OD |--|-->Rx L2 215 +---+ | | | | | | | | | | | | +--+ 216 +---+ | | | | | +------+ | | | | | +--+ 217 Tx L3----|->| / | DWDM | | ^ | DWDM | \ |--|-->Rx L3 218 +---+ | | / | Link +----|--|----+ Link | \ | | +--+ 219 +-----------+ | | +----------+ 220 +--+ +--+ 221 | | 222 Rs v | Ss 223 +-----+ +-----+ 224 |RxLx | |TxLx | 225 +-----+ +-----+ 226 Ss = reference point at the DWDM network element tributary output 227 Rs = reference point at the DWDM network element tributary input 228 Lx = Lambda x 229 OM = Optical Mux 230 OD = Optical Demux 231 OADM = Optical Add Drop Mux 233 from Fig. 5.1/G.698.2 235 Figure 1: Linear Black Link approach 237 G.698.2 [ITU.G698.2] defines also Ring "Black Link" approach 238 configurations [Fig. 5.2/G.698.2] and Linear "black link" approach 239 for Bidirectional applications[Fig. 5.3/G.698.2] 241 4.1. Use Cases 243 The use cases described below are assuming that power monitoring 244 functions are available in the ingress and egress network element of 245 the DWDM network, respectively. By performing link property 246 correlation it would be beneficial to include the current transmit 247 power value at reference point Ss and the current received power 248 value at reference point Rs. For example if the Client transmitter 249 power (OXC1) has a value of 0dBm and the ROADM interface measured 250 power (at OLS1) is -6dBm the fiber patch cord connecting the two 251 nodes may be pinched or the connectors are dirty. More, the 252 interface characteristics can be used by the OLS network Control 253 Plane in order to check the Optical Channels feasibility. Finally 254 the OXC1 transceivers parameters (Application Code) can be shared 255 with OXC2 using the LMP protocol to verify the Transceivers 256 compatibility. The actual route selection of a specific wavelength 257 within the allowed set is outside the scope of LMP. In GMPLS, the 258 parameter selection (e.g. central frequency) is performed by RSVP-TE. 260 G.698.2 defines a single channel optical interface for DWDM systems 261 that allows interconnecting network-external optical transponders 262 across a DWDM network. The optical transponders are considered to be 263 external to the DWDM network. This so-called 'black link' approach 264 illustrated in Figure 5-1 of G.698.2 and a copy of this figure is 265 provided below. The single channel fiber link between the Ss/Rs 266 reference points and the ingress/egress port of the network element 267 on the domain boundary of the DWDM network (DWDM border NE) is called 268 access link in this contribution. Based on the definition in G.698.2 269 it is considered to be part of the DWDM network. The access link 270 typically is realized as a passive fiber link that has a specific 271 optical attenuation (insertion loss). As the access link is an 272 integral part of the DWDM network, it is desirable to monitor its 273 attenuation. Therefore, it is useful to detect an increase of the 274 access link attenuation, for example, when the access link fiber has 275 been disconnected and reconnected (maintenance) and a bad patch panel 276 connection (connector) resulted in a significantly higher access link 277 attenuation (loss of signal in the extreme case of an open connector 278 or a fiber cut). In the following section, two use cases are 279 presented and discussed: 281 1) pure access link monitoring 282 2) access link monitoring with a power control loop 284 These use cases require a power monitor as described in G.697 (see 285 section 6.1.2), that is capable to measure the optical power of the 286 incoming or outgoing single channel signal. The use case where a 287 power control loop is in place could even be used to compensate an 288 increased attenuation as long as the optical transmitter can still be 289 operated within its output power range defined by its application 290 code. 292 Figure 2 Access Link Power Monitoring 294 +--------------------------+ 295 | P(in) = P(Tx) - a(Tx) | 296 | ___ | 297 +----------+ | \ / Power Monitor | 298 | | P(Tx) | V | 299 | +----+ | Ss //\\ | | |\ | 300 | | TX |----|-----\\//------------------->| \ | 301 | +----+ | Access Link (AL-T) | . | | | 302 | | attenuation a(Tx) | . | |==============> 303 | | | . | | | 304 | External | | --->| / | 305 | Optical | | |/ | 306 |Transpond.| | P(out) | 307 | | | ___ | 308 | | | \ / Power Monitor | 309 | | P(Rx) | V | 310 | +----+ | Rs //\\ | | |\ | 311 | | RX |<---|-----\\//--------------------| \ | 312 | +----+ | Access Link (AL-R) | . | | | 313 | | Attenuation a(Rx) | . | |<============== 314 +----------+ | . | | | 315 | <---| / | 316 P(Rx) = P(out) - a(Rx) | |/ | 317 | | 318 | ROADM | 319 +--------------------------+ 321 - For AL-T monitoring: P(Tx) and a(Tx) must be known 322 - For AL-R monitoring: P(RX) and a(Rx) must be known 324 An alarm shall be raised if P(in) or P(Rx) drops below a 325 configured threshold (t [dB]): 326 - P(in) < P(Tx) - a(Tx) - t (Tx direction) 327 - P(Rx) < P(out) - a(Rx) - t (Rx direction) 328 - a(Tx) =| a(Rx) 330 Figure 2: Extended LMP Model 332 Pure Access Link (AL) Monitoring Use Case 334 Figure 4 illustrates the access link monitoring use case and the 335 different physical properties involved that are defined below: 337 - Ss, Rs: G.698.2 reference points 338 - P(Tx): current optical output power of transmitter Tx 339 - a(Tx): access link attenuation in Tx direction (external 340 transponder point of view) 341 - P(in): measured current optical input power at the input port 342 of border DWDM NE 343 - t: user defined threshold (tolerance) 344 - P(out): measured current optical output power at the output 345 port of border DWDM NE 346 - a(Rx): access link attenuation in Rx direction (external 347 transponder point of view) 348 - P(Rx): current optical input power of receiver Rx 350 Assumptions: 351 - The access link attenuation in both directions (a(Tx), a(Rx)) 352 is known or can be determined as part of the commissioning 353 process. Typically, both values are the same. 354 - A threshold value t has been configured by the operator. This 355 should also be done during commissioning. 356 - A control plane protocol is in place that allows 357 to periodically send the optical power values P(Tx) and P(Rx) 358 to the control plane protocol instance on the DWDM border NE. 359 This is llustrated in Figure 3. 360 - The DWDM border NE is capable to periodically measure the optical 361 power Pin and Pout as defined in G.697 by power monitoring points 362 depicted as yellow triangles in the figures below. 364 AL monitoring process: 365 - Tx direction: the measured optical input power Pin is compared 366 with the expected optical input power P(Tx) - a(Tx). If the 367 measured optical input power P(in) drops below the value 368 (P(Tx) - a(Tx) - t) a low power alarm shall be raised indicating 369 that the access link attenuation has exceeded a(Tx) + t. 370 - Rx direction: the measured optical input power P(Rx) is 371 compared with the expected optical input power P(out) - a(Rx). 372 If the measured optical input power P(Rx) drops below the value 373 (P(out) - a(Rx) - t) a 374 low power alarm shall be raised indicating that the access link 375 attenuation has exceeded a(Rx) + t. 377 Figure 3 Use case 1: Access Link power monitoring 379 +----------+ +--------------------------+ 380 | +------+ | P(Tx), P(Rx) | +-------+ | 381 | | | | =================> | | | | 382 | | LMP | | P(in), P(out) | | LMP | | 383 | | | | <================= | | | | 384 | +------+ | | +-------+ | 385 | | | | 386 | | | P(in) - P(Tx) - a(Tx) | 387 | | | ___ | 388 | | | \ / Power Monitor | 389 | | P(Tx) | V | 390 | +----+ | Ss //\\ | | |\ | 391 | | TX |----|-----\\//------------------->| \ | 392 | +----+ | Access Link (AL-T) | . | | | 393 | | attenuation a(Tx) | . | |==============> 394 | | | . | | | 395 | External | | --->| / | 396 | Optical | | |/ | 397 |Transpond.| | P(out) | 398 | | | ___ | 399 | | | \ / Power Monitor | 400 | | P(Rx) | V | 401 | +----+ | Rs //\\ | | |\ | 402 | | RX |<---|-----\\//--------------------| \ | 403 | +----+ | Access Link (AL-R) | . | | | 404 | | Attenuation a(Rx) | . | |<============== 405 +----------+ | . | | | 406 | <---| / | 407 P(Rx) = P(out) - a(Rx) | |/ | 408 | | 409 | ROADM | 410 +--------------------------+ 412 - For AL-T monitoring: P(Tx) and a(Tx) must be known 413 - For AL-R monitoring: P(RX) and a(Rx) must be known 414 An alarm shall be raised if P(in) or P(Rx) drops below a 415 configured threshold (t [dB]): 416 - P(in) < P(Tx) - a(Tx) - t (Tx direction) 417 - P(Rx) < P(out) - a(Rx) - t (Rx direction) 418 - a(Tx) = a(Rx) 420 Figure 3: Extended LMP Model 422 Power Control Loop Use Case 424 This use case is based on the access link monitoring use case as 425 described above. In addition, the border NE is running a power 426 control application that is capable to control the optical output 427 power of the single channel tributary signal at the output port 428 of the border DWDM NE (towards the external receiver Rx) and the 429 optical output power of the single channel tributary signal at 430 the external transmitter Tx within their known operating range. 431 The time scale of this control loop is typically relatively slow 432 (e.g. some 10s or minutes) because the access link attenuation 433 is not expected to vary much over time (the attenuation only 434 changes when re-cabling occurs). 435 From a data plane perspective, this use case does not require 436 additional data plane extensions. It does only require a protocol 437 extension in the control plane (e.g. this LMP draft) that allows 438 the power control application residing in the DWDM border NE to 439 modify the optical output power of the DWDM domain-external 440 transmitter Tx within the range of the currently used application 441 code. Figure 5 below illustrates this use case utilizing the LMP 442 protocol with extensions defined in this draft. 444 Figure 4 Use case 2: Power Control Loop 446 +----------+ +--------------------------+ 447 | +------+ | P(Tx),P(Rx),Set(Pout) | +-------+ +--------+ | 448 | | | | ====================> | | | | Power | | 449 | | LMP | | P(in),P(out),Set(PTx) | | LMP | |Control | | 450 | | | | <==================== | | | | Loop | | 451 | +------+ | | +-------+ +--------+ | 452 | | | | | 453 | +------+ | | P(in) = P(Tx) - a(Tx) | 454 | |C.Loop| | | ___ | 455 | +------+ | | \ / Power Monitor | 456 | | | P(Tx) | V | 457 | +------+ | Ss //\\ | | |\ | 458 | | TX |>---|-----\\//---------------------->| \ | 459 | +------+ | Access Link (AL-T) | . | | | 460 | VOA(Tx) | attenuation a(Tx) | . | |==============> 461 | | | . | | | 462 | External | | --->| / | 463 | Optical | | |/ | 464 |Transpond.| | P(out) | 465 | | | ___ | 466 | | | \ / Power Monitor | 467 | | P(Rx) | V | 468 | +----+ | Rs //\\ | | VOA(out) |\ | 469 | | RX |<---|-----\\//---------------------<|-------| \ | 470 | +----+ | Access Link (AL-R) | . | | | 471 | | attenuation a(Rx) | . | |<======= 472 +----------+ | VOA(out) | | | 473 | <--<|-------| / | 474 P(Rx) = P(out) - a(Rx) | |/ | 475 | | 476 | ROADM | 477 +--------------------------+ 479 The Power Control Loops in Transponder and ROADM regulate 480 the Variable Optical Attenuators (VOA) to adjust the 481 proper power in base of the ROADM and Receiver 482 caracteristics and the Access Link attenuation 484 Figure 4: Extended LMP Model 486 4.2. Optical Parameters Description 488 The G.698.2 pre-certified network media channels are managed at the 489 edges, i.e. at the transmitters (Tx) and receivers (Rx) attached to 490 the S and R reference points respectively. The set of parameters 491 that could be managed are specified in G.698.2 [ITU.G698.2] section 492 5.3 referring the "application code" notation 494 The definitions of the optical parameters are provided below to 495 increase the readability of the document, where the definition is 496 ended by (G) the parameter can be retrieve with a GET, when (S) it 497 can be provisioned by a SET, (G,S) can be either GET and SET. 499 To support the management of these parameters, the SNMP MIB in RFC 500 3591 [RFC3591] is extended with a new MIB module defined in section 6 501 of this document. This new MIB module includes the definition of new 502 configuration table of the OCh Layer for the parameters at Tx (S) and 503 Rx (R). 505 4.2.1. Rs-Ss Configuration 507 The Rs-Ss configuration table allows configuration of Central 508 Frequency, Power and Application identifiers as described in 509 [ITU.G698.2] and G.694.1 [ITU.G694.1] 510 This parameter report the current Transceiver Output power, it can be 511 either a setting and measured value (G, S). 513 Central frequency (see G.694.1 Table 1): 514 This parameter indicates the central frequency value that Ss and 515 Rs will be set, to work (in THz), in particular Section 6/G.694.1 516 (G, S). 518 Single-channel application identifiers (see G.698.2): 519 This parameter indicates the transceiver application identifier at 520 Ss and Rs as defined in [ITU.G698.2] Chapter 5.4 - this parameter 521 can be called Optical Interface Identifier OII as per [draft- 522 martinelli-wson-interface-class] (G). 524 Number of Single-channel application identifiers Supported 525 This parameter indicates the number of Single-channel application 526 codes supported by this interface (G). 528 Current Laser Output power: 529 This parameter report the current Transceiver Output power, see 530 RFC3591. 532 Current Laser Input power: 534 This parameter report the current Transceiver Input power see 535 RFC3591. 537 +---------------------------------------------+---------+-----------+ 538 | PARAMETERS | Get/Set | Reference | 539 +---------------------------------------------+---------+-----------+ 540 | Central Frequency | G,S | G.694.1 | 541 | | | S.6 | 542 | Single-channel Application Identifier | G | G.874.1 | 543 | number in use | | | 544 | Single-channel Application Identifier Type | G | G.874.1 | 545 | in use | | | 546 | Single-channel Application Identifier in | G | G.874.1 | 547 | use | | | 548 | Number of Single-channel Application | G | N.A. | 549 | Identifiers Supported | | | 550 | Current Output Power | G,S | RFC3591 | 551 | Current Input Power | G | RFC3591 | 552 +---------------------------------------------+---------+-----------+ 554 Table 1: Rs-Ss Configuration 556 4.2.2. Table of Application Identifiers 558 This table has a list of Application Identifiers supported by this 559 interface at point R are defined in G.698.2. 561 Application Identifier Number: 562 The number that uniquely identifies the Application Identifier. 564 Application Identifier Type: 565 Type of application Identifier: STANDARD / PROPRIETARY in G.874.1 567 Note: if the A.I. type = PROPRIETARY, the first 6 Octets of the 568 Application Identifier (PrintableString) must contain the 569 Hexadecimal representation of an OUI (organizationally unique 570 identifier) assigned to the vendor whose implementation generated 571 the Application Identifier; the remaining octets of the 572 PrintableString are unspecified. 574 Application Identifier: 575 This is the application Identifier that is defined in G.874.1. 577 4.3. Use of ifTable 579 This section specifies how the MIB II interfaces group, as defined in 580 RFC 2863 [RFC2863], is used for the link ends of a black link. Only 581 the ifGeneralInformationGroup will be supported for the ifTable and 582 the ifStackTable to maintain the relationship between the OCh and OPS 583 layers. The OCh and OPS layers are managed in the ifTable using 584 IfEntries that correlate to the layers depicted in Figure 1. 586 For example, a device with TX and/or RX will have an Optical Physical 587 Section (OPS) layer, and an OCh layer. There is a one to n 588 relationship between the OPS and OCh layers. 590 EDITOR NOTE: Reason for changing from OChr to OCh: Edition 3 of G.872 591 removed OChr from the architecture and G.709 was subsequently updated 592 to account for this architectural change. 594 Figure 5 In the following figures, opticalPhysicalSection are 595 abbreviated as OPS. 597 _____________________ 598 \ 599 Path Data Unit |\ 600 (ODUk) | \ 601 _____________________| \ __________________ 602 | | | > 603 Tandem Data Unit | | | | 604 (ODUkT) | | OCh Layer | > n och IfEntries 605 _____________________| | | | 606 | |__________________| > 607 Optical | /| | > 608 Transport Unit | / | | | 609 (OTUk) |/ | OPSn Layer | > m ops IfEntries 610 _____________________/ | | | 611 |__________________| > 613 Figure 5: OTN Layers for OPS and OCh 615 Each opticalChannel IfEntry is mapped to one of the m 616 opticalPhysicalSection IfEntries, where m is greater than or equal to 617 1. Conversely, each opticalTransPhysicalSection port entry is mapped 618 to one of the n opticalChannel IfEntries, where n is greater than or 619 equal to 1. 621 The design of the Optical Interface MIB provides the option to model 622 an interface either as a single bidirectional object containing both 623 sink and source functions or as a pair of unidirectional objects, one 624 containing sink functions and the other containing source functions. 626 If the sink and source for a given protocol layer are to be modelled 627 as separate objects, then there need to be two ifTable entries, one 628 that corresponds to the sink and one that corresponds to the source, 629 where the directionality information is provided in the configuration 630 tables for that layer via the associated Directionality objects. The 631 agent is expected to maintain consistent directionality values 632 between ifStackTable layers (e.g., a sink must not be stacked in a 633 1:1 manner on top of a source, or vice-versa), and all protocol 634 layers that are represented by a given ifTable entry are expected to 635 have the same directionality. 637 When separate ifTable entries are used for the source and sink 638 functions of a given physical interface, association between the two 639 uni-directional ifTable entries (one for the source function and the 640 other for the sink functions) should be provided. It is recommended 641 that identical ifName values are used for the two ifTable entries to 642 indicate such association. An implementation shall explicitly state 643 what mechanism is used to indicate the association, if ifName is not 644 used. 646 4.3.1. Use of ifTable for OPS Layer 648 Only the ifGeneralInformationGroup needs to be supported. 650 ifTable Object Use for OTN OPS Layer 651 ================================================================== 653 ifIndex The interface index. 655 ifDescr Optical Transport Network (OTN) Optical 656 Physical Section (OPS) 658 ifType opticalPhysicalSection (xxx) 660 <<>> 662 ifSpeed Actual bandwidth of the interface in bits per 663 second. If the bandwidth of the interface is 664 greater than the maximum value of 4,294,967,295 665 then the maximum value is reported and 666 ifHighSpeed must be used to report the 667 interface's speed. 669 ifPhysAddress An octet string with zero length. (There is 670 no specific address associated with the 671 interface.) 673 ifAdminStatus The desired administrative state of the 674 interface. Supports read-only access. 676 ifOperStatus The operational state of the interface. The 677 value lowerLayerDown(7) is not used, since 678 there is no lower layer interface. This object 679 is set to notPresent(6) if a component is 680 missing, otherwise it is set to down(2) if 681 either of the objects optIfOPSnCurrentStatus 682 indicates that any defect is present. 684 ifLastChange The value of sysUpTime at the last change in 685 ifOperStatus. 687 ifName Enterprise-specific convention (e.g., TL-1 AID) 688 to identify the physical or data entity 689 associated with this interface or an 690 OCTET STRING of zero length. The 691 enterprise-specific convention is intended to 692 provide the means to reference one or more 693 enterprise-specific tables. 695 ifLinkUpDownTrapEnable Default value is enabled(1). Supports 696 read-only access. 698 ifHighSpeed Actual bandwidth of the interface in Mega-bits 699 per second. A value of n represents a range of 700 'n-0.5' to 'n+0.499999'. 702 ifConnectorPresent Set to true(1). 704 ifAlias The (non-volatile) alias name for this interface 705 as assigned by the network manager. 707 4.3.2. Use of ifTable for OCh Layer 709 Use of ifTable for OCh Layer See RFC 3591 [RFC3591] section 2.4 711 4.3.3. Use of ifStackTable 713 Use of the ifStackTable and ifInvStackTable to associate the 714 opticalPhysicalSection and opticalChannel interface entries is best 715 illustrated by the example shown in Figure 3. The example assumes an 716 ops interface with ifIndex i that carries two multiplexed OCh 717 interfaces with ifIndex values of j and k, respectively. The example 718 shows that j and k are stacked above (i.e., multiplexed into) i. 719 Furthermore, it shows that there is no layer lower than i and no 720 layer higher than j and/or k. 722 Figure 6 724 HigherLayer LowerLayer 725 -------------------------- 726 0 j 727 0 k 728 j i 729 k i 730 i 0 732 Figure 6: Use of ifStackTable for an OTN port 734 For the inverse stack table, it provides the same information as the 735 interface stack table, with the order of the Higher and Lower layer 736 interfaces reversed. 738 5. Structure of the MIB Module 740 EDITOR NOTE:text will be provided based on the MIB module in 741 Section 6 743 6. Object Definitions 745 EDITOR NOTE: Once the scope in Section 1 and the parameters in 746 Section 4 are finalized, a MIB module will be defined. It could be 747 an extension to the OPT-IF-MIB module of RFC 3591. >>> 748 OPT-IF-698-MIB DEFINITIONS ::= BEGIN 750 IMPORTS 751 MODULE-IDENTITY, 752 OBJECT-TYPE, 753 Gauge32, 754 Integer32, 755 Unsigned32, 756 Counter64, 757 transmission, 758 NOTIFICATION-TYPE 759 FROM SNMPv2-SMI 760 TEXTUAL-CONVENTION, 761 RowPointer, 762 RowStatus, 763 TruthValue, 764 DisplayString, 765 DateAndTime 766 FROM SNMPv2-TC 767 SnmpAdminString 768 FROM SNMP-FRAMEWORK-MIB 769 MODULE-COMPLIANCE, OBJECT-GROUP 770 FROM SNMPv2-CONF 771 ifIndex 772 FROM IF-MIB 773 optIfMibModule 774 FROM OPT-IF-MIB; 776 -- This is the MIB module for the optical parameters - 777 -- Application codes associated with the black link end points. 779 optIfXcvrMibModule MODULE-IDENTITY 780 LAST-UPDATED "201401270000Z" 781 ORGANIZATION "IETF Ops/Camp MIB Working Group" 782 CONTACT-INFO 783 "WG charter: 784 http://www.ietf.org/html.charters/ 786 Mailing Lists: 787 Editor: Gabriele Galimberti 788 Email: ggalimbe@cisco.com" 789 DESCRIPTION 790 "The MIB module to describe Black Link tranceiver 791 characteristics to rfc3591. 793 Copyright (C) The Internet Society (2014). This version 794 of this MIB module is an extension to rfc3591; see the RFC 795 itself for full legal notices." 796 REVISION "201305050000Z" 797 DESCRIPTION 798 "Draft version 1.0" 799 REVISION "201305050000Z" 800 DESCRIPTION 801 "Draft version 2.0" 802 REVISION "201302270000Z" 803 DESCRIPTION 804 "Draft version 3.0" 805 REVISION "201307020000Z" 806 DESCRIPTION 807 "Draft version 4.0 808 Changed the draft to include only the G.698 parameters." 809 REVISION "201311020000Z" 810 DESCRIPTION 811 "Draft version 5.0 812 Mib has a table of application code/vendor 813 transcievercode G.698" 814 REVISION "201401270000Z" 815 DESCRIPTION 816 "Draft version 6.0" 817 REVISION "201407220000Z" 818 DESCRIPTION 819 "Draft version 8.0 820 Removed Vendor transceiver code" 821 REVISION "201502220000Z" 822 DESCRIPTION 823 "Draft version 11.0 824 Added reference to OUI in the first 6 Octets of a 825 proprietary Application code 826 Added a Length field for the Application code 827 Changed some names" 828 REVISION "201507060000Z" 829 DESCRIPTION 830 "Draft version 12.0 831 Added Power Measurement Use Cases 832 and ITU description" " 833 ::= { optIfMibModule 4 } 835 ::= { optIfMibModule 4 } 837 -- Addition to the RFC 3591 objects 838 optIfOChSsRsGroup OBJECT IDENTIFIER ::= { optIfXcvrMibModule 1 } 839 -- OCh Ss/Rs config table 840 -- The application code/vendor tranceiver class for the Black Link 841 -- Ss-Rs will be added to the OchConfigTable 843 optIfOChSsRsConfigTable OBJECT-TYPE 844 SYNTAX SEQUENCE OF OptIfOChSsRsConfigEntry 845 MAX-ACCESS not-accessible 846 STATUS current 847 DESCRIPTION 848 "A table of Och General config extension parameters" 849 ::= { optIfOChSsRsGroup 1 } 851 optIfOChSsRsConfigEntry OBJECT-TYPE 852 SYNTAX OptIfOChSsRsConfigEntry 853 MAX-ACCESS not-accessible 854 STATUS current 855 DESCRIPTION 856 "A conceptual row that contains G.698 parameters for an 857 interface." 858 INDEX { ifIndex } 859 ::= { optIfOChSsRsConfigTable 1 } 861 OptIfOChSsRsConfigEntry ::= 862 SEQUENCE { 863 optIfOChCentralFrequency Unsigned32, 864 optIfOChCfgApplicationIdentifierNumber Unsigned32, 865 optIfOChCfgApplicationIdentifierType Unsigned32, 866 optIfOChCfgApplicationIdentifierLength Unsigned32, 867 optIfOChCfgApplicationIdentifier DisplayString, 868 optIfOChNumberApplicationCodesSupported Unsigned32 869 } 871 optIfOChCentralFrequency OBJECT-TYPE 872 SYNTAX Unsigned32 873 MAX-ACCESS read-write 874 UNITS "THz" 875 STATUS current 876 DESCRIPTION 877 " This parameter indicates the frequency of this interface. 878 " 879 ::= { optIfOChSsRsConfigEntry 1 } 881 optIfOChCfgApplicationIdentifierNumber OBJECT-TYPE 882 SYNTAX Unsigned32 883 MAX-ACCESS read-write 884 STATUS current 885 DESCRIPTION 886 "This parameter uniquely indicates the transceiver 887 application code at Ss and Rs as defined in [ITU.G874.1], 888 that is used by this interface. 889 The optIfOChSrcApplicationIdentifierTable has all the 890 application codes supported by this interface. " 891 ::= { optIfOChSsRsConfigEntry 2 } 893 optIfOChCfgApplicationIdentifierType OBJECT-TYPE 894 SYNTAX Unsigned32 895 MAX-ACCESS read-write 896 STATUS current 897 DESCRIPTION 898 "This parameter indicates the transceiver type of 899 application code at Ss and Rs as defined in [ITU.G874.1], 900 that is used by this interface. 901 The optIfOChSrcApplicationIdentifierTable has all the 902 application codes supported by this interface 903 Standard = 0, PROPRIETARY = 1. " 904 ::= { optIfOChSsRsConfigEntry 3 } 906 optIfOChCfgApplicationIdentifierLenght OBJECT-TYPE 907 SYNTAX Unsigned32 908 MAX-ACCESS read-write 909 STATUS current 910 DESCRIPTION 911 "This parameter indicates the number of octets in the 912 Application Identifier. 913 " 914 ::= { optIfOChSsRsConfigEntry 4 } 916 optIfOChCfgApplicationIdentifier OBJECT-TYPE 917 SYNTAX DisplayString 918 MAX-ACCESS read-write 919 STATUS current 920 DESCRIPTION 921 "This parameter indicates the transceiver application code 922 at Ss and Rs as defined in [ITU.G698.2] Chapter 5.3, that 923 is used by this interface. The 924 optIfOChSrcApplicationCodeTable has all the application 925 codes supported by this interface. 926 If the optIfOChCfgApplicationIdentifierType is 1 927 (Proprietary), then the first 6 octets of the printable 928 string will be the OUI (organizationally unique identifier) 929 assigned to the vendor whose implementation generated the 930 Application Identifier." 931 ::= { optIfOChSsRsConfigEntry 5 } 933 optIfOChNumberApplicationIdentifiersSupported OBJECT-TYPE 934 SYNTAX Unsigned32 935 MAX-ACCESS read-only 936 STATUS current 937 DESCRIPTION 938 " Number of Application codes supported by this interface." 939 ::= { optIfOChSsRsConfigEntry 6 } 941 -- Table of Application codes supported by the interface 942 -- OptIfOChSrcApplicationCodeEntry 944 optIfOChSrcApplicationIdentifierTable OBJECT-TYPE 945 SYNTAX SEQUENCE OF OptIfOChSrcApplicationIdentifierEntry 946 MAX-ACCESS not-accessible 947 STATUS current 948 DESCRIPTION 949 "A Table of Application codes supported by this interface." 950 ::= { optIfOChSsRsGroup 2 } 952 optIfOChSrcApplicationIdentifierEntry OBJECT-TYPE 953 SYNTAX OptIfOChSrcApplicationIdentifierEntry 954 MAX-ACCESS not-accessible 955 STATUS current 956 DESCRIPTION 957 "A conceptual row that contains the Application code for 958 this interface." 959 INDEX { ifIndex, optIfOChApplicationIdentiferNumber } 960 ::= { optIfOChSrcApplicationIdentifierTable 1 } 962 OptIfOChSrcApplicationIdentifierEntry ::= 963 SEQUENCE { 964 optIfOChApplicationIdentiferNumber Integer32, 965 optIfOChApplicationIdentiferType Integer32, 966 optIfOChApplicationIdentiferLength Integer32, 967 optIfOChApplicationIdentifier DisplayString 968 } 970 optIfOChApplicationIdentiferNumber OBJECT-TYPE 971 SYNTAX Integer32 (1..255) 972 MAX-ACCESS not-accessible 973 STATUS current 974 DESCRIPTION 975 " The number/identifier of the application code supported at 976 this interface. The interface can support more than one 977 application codes. 978 " 979 ::= { optIfOChSrcApplicationIdentifierEntry 1} 981 optIfOChApplicationIdentiferType OBJECT-TYPE 982 SYNTAX Integer32 (1..255) 983 MAX-ACCESS read-only 984 STATUS current 985 DESCRIPTION 986 " The type of identifier of the application code supported at 987 this interface. The interface can support more than one 988 application codes. 989 Standard = 0, PROPRIETARY = 1 990 " 991 ::= { optIfOChSrcApplicationIdentifierEntry 2} 993 optIfOChApplicationIdentiferLength OBJECT-TYPE 994 SYNTAX Integer32 (1..255) 995 MAX-ACCESS read-only 996 STATUS current 997 DESCRIPTION 998 " This parameter indicates the number of octets in the 999 Application Identifier. 1000 " 1001 ::= { optIfOChSrcApplicationIdentifierEntry 3} 1003 optIfOChApplicationIdentifier OBJECT-TYPE 1004 SYNTAX DisplayString 1005 MAX-ACCESS read-only 1006 STATUS current 1007 DESCRIPTION 1008 " The application code supported by this interface DWDM 1009 link. 1010 If the optIfOChApplicationIdentiferType is 1 (Proprietary), 1011 then the first 6 octets of the printable string will be 1012 the OUI (organizationally unique identifier) assigned to 1013 the vendor whose implementation generated the Application 1014 Identifier." 1015 ::= { optIfOChSrcApplicationIdentifierEntry 4} 1017 -- Notifications 1019 -- Central Frequency Change Notification 1020 optIfOChCentralFrequencyChange NOTIFICATION-TYPE 1021 OBJECTS { optIfOChCentralFrequency } 1022 STATUS current 1023 DESCRIPTION 1024 "Notification of a change in the central frequency." 1026 ::= { optIfXcvrMibModule 1 } 1028 END 1030 7. Relationship to Other MIB Modules 1032 7.1. Relationship to the [TEMPLATE TODO] MIB 1034 7.2. MIB modules required for IMPORTS 1036 8. Definitions 1038 [TEMPLATE TODO]: put your valid MIB module here. 1039 A list of tools that can help automate the process of 1040 checking MIB definitions can be found at 1041 http://www.ops.ietf.org/mib-review-tools.html 1043 9. Security Considerations 1045 There are a number of management objects defined in this MIB module 1046 with a MAX-ACCESS clause of read-write and/or read-create. Such 1047 objects may be considered sensitive or vulnerable in some network 1048 environments. The support for SET operations in a non-secure 1049 environment without proper protection can have a negative effect on 1050 network operations. These are the tables and objects and their 1051 sensitivity/vulnerability: 1053 o 1055 Some of the readable objects in this MIB module (i.e., objects with a 1056 MAX-ACCESS other than not-accessible) may be considered sensitive or 1057 vulnerable in some network environments. It is thus important to 1058 control even GET and/or NOTIFY access to these objects and possibly 1059 to even encrypt the values of these objects when sending them over 1060 the network via SNMP. 1062 SNMP versions prior to SNMPv3 did not include adequate security. 1063 Even if the network itself is secure (for example by using IPsec), 1064 even then, there is no control as to who on the secure network is 1065 allowed to access and GET/SET (read/change/create/delete) the objects 1066 in this MIB module. 1068 It is RECOMMENDED that implementers consider the security features as 1069 provided by the SNMPv3 framework (see [RFC3410], section 8), 1070 including full support for the SNMPv3 cryptographic mechanisms (for 1071 authentication and privacy). 1073 Further, deployment of SNMP versions prior to SNMPv3 is NOT 1074 RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to 1075 enable cryptographic security. It is then a customer/operator 1076 responsibility to ensure that the SNMP entity giving access to an 1077 instance of this MIB module is properly configured to give access to 1078 the objects only to those principals (users) that have legitimate 1079 rights to indeed GET or SET (change/create/delete) them. 1081 10. IANA Considerations 1083 Option #1: 1085 The MIB module in this document uses the following IANA-assigned 1086 OBJECT IDENTIFIER values recorded in the SMI Numbers registry: 1088 Descriptor OBJECT IDENTIFIER value 1089 ---------- ----------------------- 1091 sampleMIB { mib-2 XXX } 1093 Option #2: 1095 Editor's Note (to be removed prior to publication): the IANA is 1096 requested to assign a value for "XXX" under the 'mib-2' subtree and 1097 to record the assignment in the SMI Numbers registry. When the 1098 assignment has been made, the RFC Editor is asked to replace "XXX" 1099 (here and in the MIB module) with the assigned value and to remove 1100 this note. 1102 Note well: prior to official assignment by the IANA, an internet 1103 draft MUST use place holders (such as "XXX" above) rather than actual 1104 numbers. See RFC4181 Section 4.5 for an example of how this is done 1105 in an internet draft MIB module. 1107 Option #3: 1109 This memo includes no request to IANA. 1111 11. Contributors 1112 Arnold Mattheus 1113 Deutsche Telekom 1114 Darmstadt 1115 Germany 1116 email a.mattheus@telekom.de 1118 Manuel Paul 1119 Deutsche Telekom 1120 Berlin 1121 Germany 1122 email Manuel.Paul@telekom.de 1124 Frank Luennemann 1125 Deutsche Telekom 1126 Munster 1127 Germany 1128 email Frank.Luennemann@telekom.de 1130 Scott Mansfield 1131 Ericsson Inc. 1132 email scott.mansfield@ericsson.com 1134 Najam Saquib 1135 Cisco 1136 Ludwig-Erhard-Strasse 3 1137 ESCHBORN, HESSEN 65760 1138 GERMANY 1139 email nasaquib@cisco.com 1141 Walid Wakim 1142 Cisco 1143 9501 Technology Blvd 1144 ROSEMONT, ILLINOIS 60018 1145 UNITED STATES 1146 email wwakim@cisco.com 1148 Ori Gerstel 1149 Sedona System 1150 ISRAEL 1151 email orig@sedonasys.com 1153 12. References 1155 12.1. Normative References 1157 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group 1158 MIB", RFC 2863, June 2000. 1160 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1161 Requirement Levels", BCP 14, RFC 2119, March 1997. 1163 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 1164 Schoenwaelder, Ed., "Structure of Management Information 1165 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 1167 [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. 1168 Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD 1169 58, RFC 2579, April 1999. 1171 [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, 1172 "Conformance Statements for SMIv2", STD 58, RFC 2580, 1173 April 1999. 1175 [RFC3591] Lam, H-K., Stewart, M., and A. Huynh, "Definitions of 1176 Managed Objects for the Optical Interface Type", RFC 3591, 1177 September 2003. 1179 [RFC6205] Otani, T. and D. Li, "Generalized Labels for Lambda- 1180 Switch-Capable (LSC) Label Switching Routers", RFC 6205, 1181 March 2011. 1183 [ITU.G698.2] 1184 International Telecommunications Union, "Amplified 1185 multichannel dense wavelength division multiplexing 1186 applications with single channel optical interfaces", 1187 ITU-T Recommendation G.698.2, November 2009. 1189 [ITU.G709] 1190 International Telecommunications Union, "Interface for the 1191 Optical Transport Network (OTN)", ITU-T Recommendation 1192 G.709, February 2012. 1194 [ITU.G872] 1195 International Telecommunications Union, "Architecture of 1196 optical transport networks", ITU-T Recommendation G.872 1197 and Amd.1, October 2012. 1199 [ITU.G798] 1200 International Telecommunications Union, "Characteristics 1201 of optical transport network hierarchy equipment 1202 functional blocks", ITU-T Recommendation G.798 and Amd.1, 1203 December 2012. 1205 [ITU.G874] 1206 International Telecommunications Union, "Management 1207 aspects of optical transport network elements", ITU-T 1208 Recommendation G.874, August 2013. 1210 [ITU.G874.1] 1211 International Telecommunications Union, "Optical transport 1212 network (OTN): Protocol-neutral management information 1213 model for the network element view", ITU-T Recommendation 1214 G.874.1, October 2012. 1216 [ITU.G959.1] 1217 International Telecommunications Union, "Optical transport 1218 network physical layer interfaces", ITU-T Recommendation 1219 G.959.1, November 2009. 1221 [ITU.G826] 1222 International Telecommunications Union, "End-to-end error 1223 performance parameters and objectives for international, 1224 constant bit-rate digital paths and connections", ITU-T 1225 Recommendation G.826, November 2009. 1227 [ITU.G8201] 1228 International Telecommunications Union, "Error performance 1229 parameters and objectives for multi-operator international 1230 paths within the Optical Transport Network (OTN)", ITU-T 1231 Recommendation G.8201, April 2011. 1233 [ITU.G694.1] 1234 International Telecommunications Union, "Spectral grids 1235 for WDM applications: DWDM frequency grid", ITU-T 1236 Recommendation G.694.1, February 2012. 1238 [ITU.G7710] 1239 International Telecommunications Union, "Common equipment 1240 management function requirements", ITU-T Recommendation 1241 G.7710, February 2012. 1243 12.2. Informative References 1245 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 1246 "Introduction and Applicability Statements for Internet- 1247 Standard Management Framework", RFC 3410, December 2002. 1249 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 1250 June 1999. 1252 [RFC4181] Heard, C., "Guidelines for Authors and Reviewers of MIB 1253 Documents", BCP 111, RFC 4181, September 2005. 1255 [I-D.kunze-g-698-2-management-control-framework] 1256 Kunze, R., "A framework for Management and Control of 1257 optical interfaces supporting G.698.2", draft-kunze- 1258 g-698-2-management-control-framework-00 (work in 1259 progress), July 2011. 1261 [RFC4054] Strand, J. and A. Chiu, "Impairments and Other Constraints 1262 on Optical Layer Routing", RFC 4054, May 2005. 1264 Appendix A. Change Log 1266 This optional section should be removed before the internet draft is 1267 submitted to the IESG for publication as an RFC. 1269 Note to RFC Editor: please remove this appendix before publication as 1270 an RFC. 1272 Appendix B. Open Issues 1274 Note to RFC Editor: please remove this appendix before publication as 1275 an RFC. 1277 Authors' Addresses 1279 Gabriele Galimberti (editor) 1280 Cisco 1281 Via Santa Maria Molgora, 48 c 1282 20871 - Vimercate 1283 Italy 1285 Phone: +390392091462 1286 Email: ggalimbe@cisco.com 1288 Ruediger Kunze (editor) 1289 Deutsche Telekom 1290 Dddd, xx 1291 Berlin 1292 Germany 1294 Phone: +49xxxxxxxxxx 1295 Email: RKunze@telekom.de 1296 Hing-Kam Lam (editor) 1297 Alcatel-Lucent 1298 600-700 Mountain Avenue, Murray Hill 1299 New Jersey, 07974 1300 USA 1302 Phone: +17323313476 1303 Email: kam.lam@alcatel-lucent.com 1305 Dharini Hiremagalur (editor) 1306 Juniper 1307 1194 N Mathilda Avenue 1308 Sunnyvale - 94089 California 1309 USA 1311 Phone: +1408 1312 Email: dharinih@juniper.net 1314 Luyuan Fang (editor) 1315 Microsoft 1316 5600 148th Ave NE 1317 Redmond, WA 98502 1318 USA 1320 Email: lufang@microsoft.com 1322 Gary Ratterree (editor) 1323 Microsoft 1324 5600 148th Ave NE 1325 Redmond, WA 98502 1326 USA 1328 Email: gratt@microsoft.com