idnits 2.17.1 draft-galikunze-ccamp-dwdm-if-snmp-mib-01.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 (March 17, 2016) is 2959 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 797, but not defined == Unused Reference: 'RFC6205' is defined on line 946, but no explicit reference was found in the text == Unused Reference: 'I-D.kdkgall-ccamp-dwdm-if-mng-ctrl-fwk' is defined on line 951, but no explicit reference was found in the text == Unused Reference: 'ITU.G709' is defined on line 963, but no explicit reference was found in the text == Unused Reference: 'ITU.G959.1' is defined on line 990, but no explicit reference was found in the text == Unused Reference: 'ITU.G826' is defined on line 995, but no explicit reference was found in the text == Unused Reference: 'ITU.G8201' is defined on line 1001, but no explicit reference was found in the text == Unused Reference: 'ITU.G7710' is defined on line 1012, but no explicit reference was found in the text == Unused Reference: 'RFC2629' is defined on line 1025, but no explicit reference was found in the text == Unused Reference: 'RFC4181' is defined on line 1029, but no explicit reference was found in the text == Outdated reference: A later version (-01) exists of draft-kdkgall-ccamp-dwdm-if-mng-ctrl-fwk-00 ** Downref: Normative reference to an Informational draft: draft-kdkgall-ccamp-dwdm-if-mng-ctrl-fwk (ref. 'I-D.kdkgall-ccamp-dwdm-if-mng-ctrl-fwk') -- 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) Summary: 2 errors (**), 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: September 18, 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 March 17, 2016 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-dwdm-if-snmp-mib-01 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 September 18, 2016. 60 Copyright Notice 62 Copyright (c) 2016 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 . . . . . . . . . . . . . 6 83 4.2.1. Rs-Ss Configuration . . . . . . . . . . . . . . . . . 6 84 4.2.2. Table of Application Identifiers . . . . . . . . . . 7 85 4.3. Use of ifTable . . . . . . . . . . . . . . . . . . . . . 8 86 4.3.1. Use of ifTable for OPS Layer . . . . . . . . . . . . 10 87 4.3.2. Use of ifTable for OCh Layer . . . . . . . . . . . . 11 88 4.3.3. Use of ifStackTable . . . . . . . . . . . . . . . . . 11 89 5. Structure of the MIB Module . . . . . . . . . . . . . . . . . 12 90 6. Object Definitions . . . . . . . . . . . . . . . . . . . . . 12 91 7. Relationship to Other MIB Modules . . . . . . . . . . . . . . 19 92 7.1. Relationship to the [TEMPLATE TODO] MIB . . . . . . . . . 19 93 7.2. MIB modules required for IMPORTS . . . . . . . . . . . . 19 94 8. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 19 95 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 96 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 97 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20 98 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 99 12.1. Normative References . . . . . . . . . . . . . . . . . . 21 100 12.2. Informative References . . . . . . . . . . . . . . . . . 24 101 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 24 102 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 24 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 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 are described in draft-kdkgall-ccamp-dwdm-if-mng-ctrl- 244 fwk 246 4.2. Optical Parameters Description 248 The G.698.2 pre-certified network media channels are managed at the 249 edges, i.e. at the transmitters (Tx) and receivers (Rx) attached to 250 the S and R reference points respectively. The set of parameters 251 that could be managed are specified in G.698.2 [ITU.G698.2] section 252 5.3 referring the "application code" notation 254 The definitions of the optical parameters are provided below to 255 increase the readability of the document, where the definition is 256 ended by (G) the parameter can be retrieve with a GET, when (S) it 257 can be provisioned by a SET, (G,S) can be either GET and SET. 259 To support the management of these parameters, the SNMP MIB in RFC 260 3591 [RFC3591] is extended with a new MIB module defined in section 6 261 of this document. This new MIB module includes the definition of new 262 configuration table of the OCh Layer for the parameters at Tx (S) and 263 Rx (R). 265 4.2.1. Rs-Ss Configuration 267 The Rs-Ss configuration table allows configuration of Central 268 Frequency, Power and Application identifiers as described in 269 [ITU.G698.2] and G.694.1 [ITU.G694.1] 270 This parameter report the current Transceiver Output power, it can be 271 either a setting and measured value (G, S). 273 Central frequency (see G.694.1 Table 1): 274 This parameter indicates the central frequency value that Ss and 275 Rs will be set, to work (in THz), in particular Section 6/G.694.1 276 (G, S). 278 Single-channel application identifiers (see G.698.2): 279 This parameter indicates the transceiver application identifier at 280 Ss and Rs as defined in [ITU.G698.2] Chapter 5.4 - this parameter 281 can be called Optical Interface Identifier OII as per [draft- 282 martinelli-wson-interface-class] (G). 284 Number of Single-channel application identifiers Supported 285 This parameter indicates the number of Single-channel application 286 codes supported by this interface (G). 288 Current Laser Output power: 289 This parameter report the current Transceiver Output power, see 290 RFC3591. 292 Current Laser Input power: 293 This parameter report the current Transceiver Input power see 294 RFC3591. 296 +---------------------------------------------+---------+-----------+ 297 | PARAMETERS | Get/Set | Reference | 298 +---------------------------------------------+---------+-----------+ 299 | Central Frequency | G,S | G.694.1 | 300 | | | S.6 | 301 | Single-channel Application Identifier | G | G.874.1 | 302 | number in use | | | 303 | Single-channel Application Identifier Type | G | G.874.1 | 304 | in use | | | 305 | Single-channel Application Identifier in | G | G.874.1 | 306 | use | | | 307 | Number of Single-channel Application | G | N.A. | 308 | Identifiers Supported | | | 309 | Current Output Power | G,S | RFC3591 | 310 | Current Input Power | G | RFC3591 | 311 +---------------------------------------------+---------+-----------+ 313 Table 1: Rs-Ss Configuration 315 4.2.2. Table of Application Identifiers 317 This table has a list of Application Identifiers supported by this 318 interface at point R are defined in G.698.2. 320 Application Identifier Number: 321 The number that uniquely identifies the Application Identifier. 323 Application Identifier Type: 324 Type of application Identifier: STANDARD / PROPRIETARY in G.874.1 326 Note: if the A.I. type = PROPRIETARY, the first 6 Octets of the 327 Application Identifier (PrintableString) must contain the 328 Hexadecimal representation of an OUI (organizationally unique 329 identifier) assigned to the vendor whose implementation generated 330 the Application Identifier; the remaining octets of the 331 PrintableString are unspecified. 333 Application Identifier: 334 This is the application Identifier that is defined in G.874.1. 336 4.3. Use of ifTable 338 This section specifies how the MIB II interfaces group, as defined in 339 RFC 2863 [RFC2863], is used for the link ends of a black link. Only 340 the ifGeneralInformationGroup will be supported for the ifTable and 341 the ifStackTable to maintain the relationship between the OCh and OPS 342 layers. The OCh and OPS layers are managed in the ifTable using 343 IfEntries that correlate to the layers depicted in Figure 1. 345 For example, a device with TX and/or RX will have an Optical Physical 346 Section (OPS) layer, and an OCh layer. There is a one to n 347 relationship between the OPS and OCh layers. 349 EDITOR NOTE: Reason for changing from OChr to OCh: Edition 3 of G.872 350 removed OChr from the architecture and G.709 was subsequently updated 351 to account for this architectural change. 353 Figure 2 In the following figures, opticalPhysicalSection are 354 abbreviated as OPS. 356 _____________________ 357 \ 358 Path Data Unit |\ 359 (ODUk) | \ 360 _____________________| \ __________________ 361 | | | > 362 Tandem Data Unit | | | | 363 (ODUkT) | | OCh Layer | > n och IfEntries 364 _____________________| | | | 365 | |__________________| > 366 Optical | /| | > 367 Transport Unit | / | | | 368 (OTUk) |/ | OPSn Layer | > m ops IfEntries 369 _____________________/ | | | 370 |__________________| > 372 Figure 2: OTN Layers for OPS and OCh 374 Each opticalChannel IfEntry is mapped to one of the m 375 opticalPhysicalSection IfEntries, where m is greater than or equal to 376 1. Conversely, each opticalTransPhysicalSection port entry is mapped 377 to one of the n opticalChannel IfEntries, where n is greater than or 378 equal to 1. 380 The design of the Optical Interface MIB provides the option to model 381 an interface either as a single bidirectional object containing both 382 sink and source functions or as a pair of unidirectional objects, one 383 containing sink functions and the other containing source functions. 385 If the sink and source for a given protocol layer are to be modelled 386 as separate objects, then there need to be two ifTable entries, one 387 that corresponds to the sink and one that corresponds to the source, 388 where the directionality information is provided in the configuration 389 tables for that layer via the associated Directionality objects. The 390 agent is expected to maintain consistent directionality values 391 between ifStackTable layers (e.g., a sink must not be stacked in a 392 1:1 manner on top of a source, or vice-versa), and all protocol 393 layers that are represented by a given ifTable entry are expected to 394 have the same directionality. 396 When separate ifTable entries are used for the source and sink 397 functions of a given physical interface, association between the two 398 uni-directional ifTable entries (one for the source function and the 399 other for the sink functions) should be provided. It is recommended 400 that identical ifName values are used for the two ifTable entries to 401 indicate such association. An implementation shall explicitly state 402 what mechanism is used to indicate the association, if ifName is not 403 used. 405 4.3.1. Use of ifTable for OPS Layer 407 Only the ifGeneralInformationGroup needs to be supported. 409 ifTable Object Use for OTN OPS Layer 410 ================================================================== 412 ifIndex The interface index. 414 ifDescr Optical Transport Network (OTN) Optical 415 Physical Section (OPS) 417 ifType opticalPhysicalSection (xxx) 419 <<>> 421 ifSpeed Actual bandwidth of the interface in bits per 422 second. If the bandwidth of the interface is 423 greater than the maximum value of 4,294,967,295 424 then the maximum value is reported and 425 ifHighSpeed must be used to report the 426 interface's speed. 428 ifPhysAddress An octet string with zero length. (There is 429 no specific address associated with the 430 interface.) 432 ifAdminStatus The desired administrative state of the 433 interface. Supports read-only access. 435 ifOperStatus The operational state of the interface. The 436 value lowerLayerDown(7) is not used, since 437 there is no lower layer interface. This object 438 is set to notPresent(6) if a component is 439 missing, otherwise it is set to down(2) if 440 either of the objects optIfOPSnCurrentStatus 441 indicates that any defect is present. 443 ifLastChange The value of sysUpTime at the last change in 444 ifOperStatus. 446 ifName Enterprise-specific convention (e.g., TL-1 AID) 447 to identify the physical or data entity 448 associated with this interface or an 449 OCTET STRING of zero length. The 450 enterprise-specific convention is intended to 451 provide the means to reference one or more 452 enterprise-specific tables. 454 ifLinkUpDownTrapEnable Default value is enabled(1). Supports 455 read-only access. 457 ifHighSpeed Actual bandwidth of the interface in Mega-bits 458 per second. A value of n represents a range of 459 'n-0.5' to 'n+0.499999'. 461 ifConnectorPresent Set to true(1). 463 ifAlias The (non-volatile) alias name for this interface 464 as assigned by the network manager. 466 4.3.2. Use of ifTable for OCh Layer 468 Use of ifTable for OCh Layer See RFC 3591 [RFC3591] section 2.4 470 4.3.3. Use of ifStackTable 472 Use of the ifStackTable and ifInvStackTable to associate the 473 opticalPhysicalSection and opticalChannel interface entries is best 474 illustrated by the example shown in Figure 3. The example assumes an 475 ops interface with ifIndex i that carries two multiplexed OCh 476 interfaces with ifIndex values of j and k, respectively. The example 477 shows that j and k are stacked above (i.e., multiplexed into) i. 478 Furthermore, it shows that there is no layer lower than i and no 479 layer higher than j and/or k. 481 Figure 3 483 HigherLayer LowerLayer 484 -------------------------- 485 0 j 486 0 k 487 j i 488 k i 489 i 0 491 Figure 3: Use of ifStackTable for an OTN port 493 For the inverse stack table, it provides the same information as the 494 interface stack table, with the order of the Higher and Lower layer 495 interfaces reversed. 497 5. Structure of the MIB Module 499 EDITOR NOTE:text will be provided based on the MIB module in 500 Section 6 502 6. Object Definitions 504 EDITOR NOTE: Once the scope in Section 1 and the parameters in 505 Section 4 are finalized, a MIB module will be defined. It could be 506 an extension to the OPT-IF-MIB module of RFC 3591. >>> 507 OPT-IF-698-MIB DEFINITIONS ::= BEGIN 509 IMPORTS 510 MODULE-IDENTITY, 511 OBJECT-TYPE, 512 Gauge32, 513 Integer32, 514 Unsigned32, 515 Counter64, 516 transmission, 517 NOTIFICATION-TYPE 518 FROM SNMPv2-SMI 519 TEXTUAL-CONVENTION, 520 RowPointer, 521 RowStatus, 522 TruthValue, 523 DisplayString, 524 DateAndTime 525 FROM SNMPv2-TC 526 SnmpAdminString 527 FROM SNMP-FRAMEWORK-MIB 528 MODULE-COMPLIANCE, OBJECT-GROUP 529 FROM SNMPv2-CONF 530 ifIndex 531 FROM IF-MIB 532 optIfMibModule 533 FROM OPT-IF-MIB; 535 -- This is the MIB module for the optical parameters - 536 -- Application codes associated with the black link end points. 538 optIfXcvrMibModule MODULE-IDENTITY 539 LAST-UPDATED "201401270000Z" 540 ORGANIZATION "IETF Ops/Camp MIB Working Group" 541 CONTACT-INFO 542 "WG charter: 543 http://www.ietf.org/html.charters/ 545 Mailing Lists: 546 Editor: Gabriele Galimberti 547 Email: ggalimbe@cisco.com" 548 DESCRIPTION 549 "The MIB module to describe Black Link tranceiver 550 characteristics to rfc3591. 552 Copyright (C) The Internet Society (2014). This version 553 of this MIB module is an extension to rfc3591; see the RFC 554 itself for full legal notices." 555 REVISION "201305050000Z" 556 DESCRIPTION 557 "Draft version 1.0" 558 REVISION "201305050000Z" 559 DESCRIPTION 560 "Draft version 2.0" 561 REVISION "201302270000Z" 562 DESCRIPTION 563 "Draft version 3.0" 564 REVISION "201307020000Z" 565 DESCRIPTION 566 "Draft version 4.0 567 Changed the draft to include only the G.698 parameters." 568 REVISION "201311020000Z" 569 DESCRIPTION 570 "Draft version 5.0 571 Mib has a table of application code/vendor 572 transcievercode G.698" 573 REVISION "201401270000Z" 574 DESCRIPTION 575 "Draft version 6.0" 576 REVISION "201407220000Z" 577 DESCRIPTION 578 "Draft version 8.0 579 Removed Vendor transceiver code" 580 REVISION "201502220000Z" 581 DESCRIPTION 582 "Draft version 11.0 583 Added reference to OUI in the first 6 Octets of a 584 proprietary Application code 585 Added a Length field for the Application code 586 Changed some names" 587 REVISION "201507060000Z" 588 DESCRIPTION 589 "Draft version 12.0 590 Added Power Measurement Use Cases 591 and ITU description" " 592 ::= { optIfMibModule 4 } 594 ::= { optIfMibModule 4 } 596 -- Addition to the RFC 3591 objects 597 optIfOChSsRsGroup OBJECT IDENTIFIER ::= { optIfXcvrMibModule 1 } 598 -- OCh Ss/Rs config table 599 -- The application code/vendor tranceiver class for the Black Link 600 -- Ss-Rs will be added to the OchConfigTable 602 optIfOChSsRsConfigTable OBJECT-TYPE 603 SYNTAX SEQUENCE OF OptIfOChSsRsConfigEntry 604 MAX-ACCESS not-accessible 605 STATUS current 606 DESCRIPTION 607 "A table of Och General config extension parameters" 608 ::= { optIfOChSsRsGroup 1 } 610 optIfOChSsRsConfigEntry OBJECT-TYPE 611 SYNTAX OptIfOChSsRsConfigEntry 612 MAX-ACCESS not-accessible 613 STATUS current 614 DESCRIPTION 615 "A conceptual row that contains G.698 parameters for an 616 interface." 617 INDEX { ifIndex } 618 ::= { optIfOChSsRsConfigTable 1 } 620 OptIfOChSsRsConfigEntry ::= 621 SEQUENCE { 622 optIfOChCentralFrequency Unsigned32, 623 optIfOChCfgApplicationIdentifierNumber Unsigned32, 624 optIfOChCfgApplicationIdentifierType Unsigned32, 625 optIfOChCfgApplicationIdentifierLength Unsigned32, 626 optIfOChCfgApplicationIdentifier DisplayString, 627 optIfOChNumberApplicationCodesSupported Unsigned32 628 } 630 optIfOChCentralFrequency OBJECT-TYPE 631 SYNTAX Unsigned32 632 MAX-ACCESS read-write 633 UNITS "THz" 634 STATUS current 635 DESCRIPTION 636 " This parameter indicates the frequency of this interface. 637 " 638 ::= { optIfOChSsRsConfigEntry 1 } 640 optIfOChCfgApplicationIdentifierNumber OBJECT-TYPE 641 SYNTAX Unsigned32 642 MAX-ACCESS read-write 643 STATUS current 644 DESCRIPTION 645 "This parameter uniquely indicates the transceiver 646 application code at Ss and Rs as defined in [ITU.G874.1], 647 that is used by this interface. 648 The optIfOChSrcApplicationIdentifierTable has all the 649 application codes supported by this interface. " 650 ::= { optIfOChSsRsConfigEntry 2 } 652 optIfOChCfgApplicationIdentifierType OBJECT-TYPE 653 SYNTAX Unsigned32 654 MAX-ACCESS read-write 655 STATUS current 656 DESCRIPTION 657 "This parameter indicates the transceiver type of 658 application code at Ss and Rs as defined in [ITU.G874.1], 659 that is used by this interface. 660 The optIfOChSrcApplicationIdentifierTable has all the 661 application codes supported by this interface 662 Standard = 0, PROPRIETARY = 1. " 663 ::= { optIfOChSsRsConfigEntry 3 } 665 optIfOChCfgApplicationIdentifierLenght OBJECT-TYPE 666 SYNTAX Unsigned32 667 MAX-ACCESS read-write 668 STATUS current 669 DESCRIPTION 670 "This parameter indicates the number of octets in the 671 Application Identifier. 672 " 673 ::= { optIfOChSsRsConfigEntry 4 } 675 optIfOChCfgApplicationIdentifier OBJECT-TYPE 676 SYNTAX DisplayString 677 MAX-ACCESS read-write 678 STATUS current 679 DESCRIPTION 680 "This parameter indicates the transceiver application code 681 at Ss and Rs as defined in [ITU.G698.2] Chapter 5.3, that 682 is used by this interface. The 683 optIfOChSrcApplicationCodeTable has all the application 684 codes supported by this interface. 685 If the optIfOChCfgApplicationIdentifierType is 1 686 (Proprietary), then the first 6 octets of the printable 687 string will be the OUI (organizationally unique identifier) 688 assigned to the vendor whose implementation generated the 689 Application Identifier." 690 ::= { optIfOChSsRsConfigEntry 5 } 692 optIfOChNumberApplicationIdentifiersSupported OBJECT-TYPE 693 SYNTAX Unsigned32 694 MAX-ACCESS read-only 695 STATUS current 696 DESCRIPTION 697 " Number of Application codes supported by this interface." 698 ::= { optIfOChSsRsConfigEntry 6 } 700 -- Table of Application codes supported by the interface 701 -- OptIfOChSrcApplicationCodeEntry 703 optIfOChSrcApplicationIdentifierTable OBJECT-TYPE 704 SYNTAX SEQUENCE OF OptIfOChSrcApplicationIdentifierEntry 705 MAX-ACCESS not-accessible 706 STATUS current 707 DESCRIPTION 708 "A Table of Application codes supported by this interface." 709 ::= { optIfOChSsRsGroup 2 } 711 optIfOChSrcApplicationIdentifierEntry OBJECT-TYPE 712 SYNTAX OptIfOChSrcApplicationIdentifierEntry 713 MAX-ACCESS not-accessible 714 STATUS current 715 DESCRIPTION 716 "A conceptual row that contains the Application code for 717 this interface." 718 INDEX { ifIndex, optIfOChApplicationIdentiferNumber } 719 ::= { optIfOChSrcApplicationIdentifierTable 1 } 721 OptIfOChSrcApplicationIdentifierEntry ::= 722 SEQUENCE { 723 optIfOChApplicationIdentiferNumber Integer32, 724 optIfOChApplicationIdentiferType Integer32, 725 optIfOChApplicationIdentiferLength Integer32, 726 optIfOChApplicationIdentifier DisplayString 727 } 729 optIfOChApplicationIdentiferNumber OBJECT-TYPE 730 SYNTAX Integer32 (1..255) 731 MAX-ACCESS not-accessible 732 STATUS current 733 DESCRIPTION 734 " The number/identifier of the application code supported at 735 this interface. The interface can support more than one 736 application codes. 737 " 738 ::= { optIfOChSrcApplicationIdentifierEntry 1} 740 optIfOChApplicationIdentiferType OBJECT-TYPE 741 SYNTAX Integer32 (1..255) 742 MAX-ACCESS read-only 743 STATUS current 744 DESCRIPTION 745 " The type of identifier of the application code supported at 746 this interface. The interface can support more than one 747 application codes. 748 Standard = 0, PROPRIETARY = 1 749 " 750 ::= { optIfOChSrcApplicationIdentifierEntry 2} 752 optIfOChApplicationIdentiferLength OBJECT-TYPE 753 SYNTAX Integer32 (1..255) 754 MAX-ACCESS read-only 755 STATUS current 756 DESCRIPTION 757 " This parameter indicates the number of octets in the 758 Application Identifier. 759 " 760 ::= { optIfOChSrcApplicationIdentifierEntry 3} 762 optIfOChApplicationIdentifier OBJECT-TYPE 763 SYNTAX DisplayString 764 MAX-ACCESS read-only 765 STATUS current 766 DESCRIPTION 767 " The application code supported by this interface DWDM 768 link. 769 If the optIfOChApplicationIdentiferType is 1 (Proprietary), 770 then the first 6 octets of the printable string will be 771 the OUI (organizationally unique identifier) assigned to 772 the vendor whose implementation generated the Application 773 Identifier." 774 ::= { optIfOChSrcApplicationIdentifierEntry 4} 776 -- Notifications 778 -- Central Frequency Change Notification 779 optIfOChCentralFrequencyChange NOTIFICATION-TYPE 780 OBJECTS { optIfOChCentralFrequency } 781 STATUS current 782 DESCRIPTION 783 "Notification of a change in the central frequency." 785 ::= { optIfXcvrMibModule 1 } 787 END 789 7. Relationship to Other MIB Modules 791 7.1. Relationship to the [TEMPLATE TODO] MIB 793 7.2. MIB modules required for IMPORTS 795 8. Definitions 797 [TEMPLATE TODO]: put your valid MIB module here. 798 A list of tools that can help automate the process of 799 checking MIB definitions can be found at 800 http://www.ops.ietf.org/mib-review-tools.html 802 9. Security Considerations 804 There are a number of management objects defined in this MIB module 805 with a MAX-ACCESS clause of read-write and/or read-create. Such 806 objects may be considered sensitive or vulnerable in some network 807 environments. The support for SET operations in a non-secure 808 environment without proper protection can have a negative effect on 809 network operations. These are the tables and objects and their 810 sensitivity/vulnerability: 812 o 814 Some of the readable objects in this MIB module (i.e., objects with a 815 MAX-ACCESS other than not-accessible) may be considered sensitive or 816 vulnerable in some network environments. It is thus important to 817 control even GET and/or NOTIFY access to these objects and possibly 818 to even encrypt the values of these objects when sending them over 819 the network via SNMP. 821 SNMP versions prior to SNMPv3 did not include adequate security. 822 Even if the network itself is secure (for example by using IPsec), 823 even then, there is no control as to who on the secure network is 824 allowed to access and GET/SET (read/change/create/delete) the objects 825 in this MIB module. 827 It is RECOMMENDED that implementers consider the security features as 828 provided by the SNMPv3 framework (see [RFC3410], section 8), 829 including full support for the SNMPv3 cryptographic mechanisms (for 830 authentication and privacy). 832 Further, deployment of SNMP versions prior to SNMPv3 is NOT 833 RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to 834 enable cryptographic security. It is then a customer/operator 835 responsibility to ensure that the SNMP entity giving access to an 836 instance of this MIB module is properly configured to give access to 837 the objects only to those principals (users) that have legitimate 838 rights to indeed GET or SET (change/create/delete) them. 840 10. IANA Considerations 842 Option #1: 844 The MIB module in this document uses the following IANA-assigned 845 OBJECT IDENTIFIER values recorded in the SMI Numbers registry: 847 Descriptor OBJECT IDENTIFIER value 848 ---------- ----------------------- 850 sampleMIB { mib-2 XXX } 852 Option #2: 854 Editor's Note (to be removed prior to publication): the IANA is 855 requested to assign a value for "XXX" under the 'mib-2' subtree and 856 to record the assignment in the SMI Numbers registry. When the 857 assignment has been made, the RFC Editor is asked to replace "XXX" 858 (here and in the MIB module) with the assigned value and to remove 859 this note. 861 Note well: prior to official assignment by the IANA, an internet 862 draft MUST use place holders (such as "XXX" above) rather than actual 863 numbers. See RFC4181 Section 4.5 for an example of how this is done 864 in an internet draft MIB module. 866 Option #3: 868 This memo includes no request to IANA. 870 11. Contributors 871 Arnold Mattheus 872 Deutsche Telekom 873 Darmstadt 874 Germany 875 email a.mattheus@telekom.de 877 Manuel Paul 878 Deutsche Telekom 879 Berlin 880 Germany 881 email Manuel.Paul@telekom.de 883 Frank Luennemann 884 Deutsche Telekom 885 Munster 886 Germany 887 email Frank.Luennemann@telekom.de 889 Scott Mansfield 890 Ericsson Inc. 891 email scott.mansfield@ericsson.com 893 Najam Saquib 894 Cisco 895 Ludwig-Erhard-Strasse 3 896 ESCHBORN, HESSEN 65760 897 GERMANY 898 email nasaquib@cisco.com 900 Walid Wakim 901 Cisco 902 9501 Technology Blvd 903 ROSEMONT, ILLINOIS 60018 904 UNITED STATES 905 email wwakim@cisco.com 907 Ori Gerstel 908 Sedona System 909 ISRAEL 910 email orig@sedonasys.com 912 12. References 914 12.1. Normative References 916 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group 917 MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000, 918 . 920 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 921 Requirement Levels", BCP 14, RFC 2119, 922 DOI 10.17487/RFC2119, March 1997, 923 . 925 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 926 Schoenwaelder, Ed., "Structure of Management Information 927 Version 2 (SMIv2)", STD 58, RFC 2578, 928 DOI 10.17487/RFC2578, April 1999, 929 . 931 [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. 932 Schoenwaelder, Ed., "Textual Conventions for SMIv2", 933 STD 58, RFC 2579, DOI 10.17487/RFC2579, April 1999, 934 . 936 [RFC2580] McCloghrie, K., Ed., Perkins, D., Ed., and J. 937 Schoenwaelder, Ed., "Conformance Statements for SMIv2", 938 STD 58, RFC 2580, DOI 10.17487/RFC2580, April 1999, 939 . 941 [RFC3591] Lam, H-K., Stewart, M., and A. Huynh, "Definitions of 942 Managed Objects for the Optical Interface Type", RFC 3591, 943 DOI 10.17487/RFC3591, September 2003, 944 . 946 [RFC6205] Otani, T., Ed. and D. Li, Ed., "Generalized Labels for 947 Lambda-Switch-Capable (LSC) Label Switching Routers", 948 RFC 6205, DOI 10.17487/RFC6205, March 2011, 949 . 951 [I-D.kdkgall-ccamp-dwdm-if-mng-ctrl-fwk] 952 Kunze, R., Grammel, G., Beller, D., and G. Galimberti, "A 953 framework for Management and Control of G.698.2 optical 954 interface parameters", draft-kdkgall-ccamp-dwdm-if-mng- 955 ctrl-fwk-00 (work in progress), October 2015. 957 [ITU.G698.2] 958 International Telecommunications Union, "Amplified 959 multichannel dense wavelength division multiplexing 960 applications with single channel optical interfaces", 961 ITU-T Recommendation G.698.2, November 2009. 963 [ITU.G709] 964 International Telecommunications Union, "Interface for the 965 Optical Transport Network (OTN)", ITU-T Recommendation 966 G.709, February 2012. 968 [ITU.G872] 969 International Telecommunications Union, "Architecture of 970 optical transport networks", ITU-T Recommendation G.872 971 and Amd.1, October 2012. 973 [ITU.G798] 974 International Telecommunications Union, "Characteristics 975 of optical transport network hierarchy equipment 976 functional blocks", ITU-T Recommendation G.798 and Amd.1, 977 December 2012. 979 [ITU.G874] 980 International Telecommunications Union, "Management 981 aspects of optical transport network elements", 982 ITU-T Recommendation G.874, August 2013. 984 [ITU.G874.1] 985 International Telecommunications Union, "Optical transport 986 network (OTN): Protocol-neutral management information 987 model for the network element view", ITU-T Recommendation 988 G.874.1, October 2012. 990 [ITU.G959.1] 991 International Telecommunications Union, "Optical transport 992 network physical layer interfaces", ITU-T Recommendation 993 G.959.1, November 2009. 995 [ITU.G826] 996 International Telecommunications Union, "End-to-end error 997 performance parameters and objectives for international, 998 constant bit-rate digital paths and connections", 999 ITU-T Recommendation G.826, November 2009. 1001 [ITU.G8201] 1002 International Telecommunications Union, "Error performance 1003 parameters and objectives for multi-operator international 1004 paths within the Optical Transport Network (OTN)", 1005 ITU-T Recommendation G.8201, April 2011. 1007 [ITU.G694.1] 1008 International Telecommunications Union, "Spectral grids 1009 for WDM applications: DWDM frequency grid", 1010 ITU-T Recommendation G.694.1, February 2012. 1012 [ITU.G7710] 1013 International Telecommunications Union, "Common equipment 1014 management function requirements", ITU-T Recommendation 1015 G.7710, February 2012. 1017 12.2. Informative References 1019 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 1020 "Introduction and Applicability Statements for Internet- 1021 Standard Management Framework", RFC 3410, 1022 DOI 10.17487/RFC3410, December 2002, 1023 . 1025 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 1026 DOI 10.17487/RFC2629, June 1999, 1027 . 1029 [RFC4181] Heard, C., Ed., "Guidelines for Authors and Reviewers of 1030 MIB Documents", BCP 111, RFC 4181, DOI 10.17487/RFC4181, 1031 September 2005, . 1033 [RFC4054] Strand, J., Ed. and A. Chiu, Ed., "Impairments and Other 1034 Constraints on Optical Layer Routing", RFC 4054, 1035 DOI 10.17487/RFC4054, May 2005, 1036 . 1038 Appendix A. Change Log 1040 This optional section should be removed before the internet draft is 1041 submitted to the IESG for publication as an RFC. 1043 Note to RFC Editor: please remove this appendix before publication as 1044 an RFC. 1046 Appendix B. Open Issues 1048 Note to RFC Editor: please remove this appendix before publication as 1049 an RFC. 1051 Authors' Addresses 1053 Gabriele Galimberti (editor) 1054 Cisco 1055 Via Santa Maria Molgora, 48 c 1056 20871 - Vimercate 1057 Italy 1059 Phone: +390392091462 1060 Email: ggalimbe@cisco.com 1061 Ruediger Kunze (editor) 1062 Deutsche Telekom 1063 Dddd, xx 1064 Berlin 1065 Germany 1067 Phone: +49xxxxxxxxxx 1068 Email: RKunze@telekom.de 1070 Hing-Kam Lam (editor) 1071 Alcatel-Lucent 1072 600-700 Mountain Avenue, Murray Hill 1073 New Jersey, 07974 1074 USA 1076 Phone: +17323313476 1077 Email: kam.lam@alcatel-lucent.com 1079 Dharini Hiremagalur (editor) 1080 Juniper 1081 1194 N Mathilda Avenue 1082 Sunnyvale - 94089 California 1083 USA 1085 Phone: +1408 1086 Email: dharinih@juniper.net 1088 Luyuan Fang (editor) 1089 Microsoft 1090 5600 148th Ave NE 1091 Redmond, WA 98502 1092 USA 1094 Email: lufang@microsoft.com 1096 Gary Ratterree (editor) 1097 Microsoft 1098 5600 148th Ave NE 1099 Redmond, WA 98502 1100 USA 1102 Email: gratt@microsoft.com