idnits 2.17.1 draft-galikunze-ccamp-g-698-2-snmp-mib-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([ITU.G698.2]), 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 == Line 672 has weird spacing: '...deTable has a...' == 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 15, 2013) is 3937 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 137, but not defined == Missing Reference: 'TEMPLATE TODO' is mentioned on line 835, but not defined == Unused Reference: 'ITU.G709' is defined on line 986, but no explicit reference was found in the text == Unused Reference: 'ITU.G872' is defined on line 991, but no explicit reference was found in the text == Unused Reference: 'ITU.G959.1' is defined on line 1013, but no explicit reference was found in the text == Unused Reference: 'ITU.G826' is defined on line 1018, but no explicit reference was found in the text == Unused Reference: 'ITU.G8201' is defined on line 1024, but no explicit reference was found in the text == Unused Reference: 'ITU.G7710' is defined on line 1035, but no explicit reference was found in the text == Unused Reference: 'RFC2629' is defined on line 1046, but no explicit reference was found in the text == Unused Reference: 'RFC4181' is defined on line 1049, but no explicit reference was found in the text == Unused Reference: 'I-D.kunze-g-698-2-management-control-framework' is defined on line 1052, 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 (~~), 15 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 16, 2014 Deutsche Telekom 6 . Kam Lam, Ed. 7 Alcatel-Lucent 8 . D. Hiremagalur, Ed. 9 Juniper 10 July 15, 2013 12 An SNMP MIB extension to RFC3591 to manage optical interface parameters 13 of DWDM applications 14 draft-galikunze-ccamp-g-698-2-snmp-mib-03 16 Abstract 18 This memo defines a module of the Management Information Base (MIB) 19 used by Simple Network Management Protocol (SNMP) in TCP/IP- based 20 internet. In particular, it defines objects for managing Optical 21 parameters associated with Dense Wavelength Division Multiplexing 22 (DWDM) interfaces. This is an extension of the RFC3591 to support 23 the optical parameters described in ITU-T G.698.2. [ITU.G698.2] 25 The MIB module defined in this memo can be used for Optical 26 Parameters monitoring and/or configuration of the endpoints of Black 27 Links. 29 Copyright Notice 31 Copyright (c) 2012 IETF Trust and the persons identified as the 32 document authors. All rights reserved. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on January 16, 2014. 50 Copyright Notice 52 Copyright (c) 2013 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. The Internet-Standard Management Framework . . . . . . . . . 4 69 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 4.1. Optical Parameters Description . . . . . . . . . . . . . 5 72 4.1.1. Rs-Ss Configuration . . . . . . . . . . . . . . . . . 6 73 4.1.2. Table of Application Codes . . . . . . . . . . . . . 7 74 4.2. Use of ifTable . . . . . . . . . . . . . . . . . . . . . 8 75 4.2.1. Use of ifTable for OPS Layer . . . . . . . . . . . . 10 76 4.2.2. Use of ifTable for OCh Layer . . . . . . . . . . . . 11 77 4.2.3. Use of ifStackTable . . . . . . . . . . . . . . . . . 11 78 5. Structure of the MIB Module . . . . . . . . . . . . . . . . . 12 79 6. Object Definitions . . . . . . . . . . . . . . . . . . . . . 12 80 7. Relationship to Other MIB Modules . . . . . . . . . . . . . . 19 81 7.1. Relationship to the [TEMPLATE TODO] MIB . . . . . . . . . 19 82 7.2. MIB modules required for IMPORTS . . . . . . . . . . . . 19 83 8. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 19 84 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 85 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 86 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 21 87 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 88 12.1. Normative References . . . . . . . . . . . . . . . . . . 22 89 12.2. Informative References . . . . . . . . . . . . . . . . . 24 90 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 24 91 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 24 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 94 1. Introduction 95 This memo defines a portion of the Management Information Base (MIB) 96 used by Simple Network Management Protocol (SNMP) in TCP/IP- based 97 internets. In particular, it defines objects for managing Optical 98 parameters associated with Wavelength Division Multiplexing (WDM) 99 systems in accordance with the optical interface defined in G.698.2 100 [ITU.G698.2] 102 Black Link approach allows supporting an optical transmitter/receiver 103 pair of one vendor to inject a DWDM channel and run it over an 104 optical network composed of amplifiers, filters, add-drop 105 multiplexers from a different vendor. From architectural point of 106 view, the "Black Link" is a set of pre-configured/qualified network 107 connections between the G.698.2 reference points S and R. The black 108 links will be managed at the edges (i.e. the transmitters and 109 receivers attached to the S and R reference points respectively) for 110 the relevant parameters specified in G.698.2 [ITU.G698.2], G.798 111 [ITU.G798], G.874 [ITU.G874], and the performance parameters 112 specified G.7710/Y.1701 [ITU-T G.7710] and and G.874.1 [ITU.G874.1]. 114 The G.698.2 [ITU.G698.2] provides optical parameter values for 115 physical layer interfaces of Dense Wavelength Division Multiplexing 116 (DWDM) systems primarily intended for metro applications which 117 include optical amplifiers. Applications are defined in G.698.2 118 [ITU.G698.2] using optical interface parameters at the single-channel 119 connection points between optical transmitters and the optical 120 multiplexer, as well as between optical receivers and the optical 121 demultiplexer in the DWDM system. This Recommendation uses a 122 methodology which does not specify the details of the optical link, 123 e.g. the maximum fibre length, explicitly. The Recommendation 124 currently includes unidirectional DWDM applications at 2.5 and 10 125 Gbit/s (with 100 GHz and 50 GHz channel frequency spacing). Work is 126 still underway for 40 and 100 Gbit/s interfaces. There is 127 possibility for extensions to a lower channel frequency spacing. 128 This document specifically refers to the "application code" defined 129 in the G.698.2 [ITU.G698.2] plus few optical paramenter not included 130 in the application code definition. 132 This draft refers and supports also the draft-kunze-g-698-2 133 -management-control-framework 135 The building of an SNMP MIB describing the optical parameters defined 136 in G.698.2 [ITU.G698.2] G.798 [ITU.G798], G.874 [ITU.G874], 137 parameters specified G.7710/Y.1701 [ITU-T G.7710] allows the 138 different vendors and operator to retrieve, provision and exchange 139 information related to Optical blak links in a standardized way. 140 This facilitates interworking in case of using optical interfaces 141 from different vendors at the end of the link. 143 The MIB, reporting the Optical parameters and their values, 144 characterizes the features and the performances of the optical 145 components and allow a reliable black link design in case of 146 multivendor optical networks. 148 Although RFC 3591 [RFC3591] describes and defines the SNMP MIB of a 149 number of key optical parameters, alarms and Performance Monitoring, 150 a more complete description of optical parameters and processes can 151 be found in the ITU-T Recommendations. Appendix A of this document 152 provides an overview about the extensive ITU-T documentation in this 153 area. The same considerations can be applied to the RFC 4054 154 [RFC4054] 156 2. The Internet-Standard Management Framework 158 For a detailed overview of the documents that describe the current 159 Internet-Standard Management Framework, please refer to section 7 of 160 RFC 3410 [RFC3410]. 162 Managed objects are accessed via a virtual information store, termed 163 the Management Information Base or MIB. MIB objects are generally 164 accessed through the Simple Network Management Protocol (SNMP). 165 Objects in the MIB are defined using the mechanisms defined in the 166 Structure of Management Information (SMI). This memo specifies a MIB 167 module that is compliant to the SMIv2, which is described in STD 58, 168 RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 169 [RFC2580]. 171 3. Conventions 173 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 174 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 175 document are to be interpreted as described in RFC 2119 [RFC2119] In 176 the description of OIDs the convention: Set (S) Get (G) and Trap (T) 177 conventions will describe the action allowed by the parameter. 179 4. Overview 181 Figure 1 shows a set of reference points, for the linear "black link" 182 approach, for single-channel connection (Ss and Rs) between 183 transmitters (Tx) and receivers (Rx). Here the DWDM network elements 184 include an OM and an OD (which are used as a pair with the opposing 185 element), one or more optical amplifiers and may also include one or 186 more OADMs. 188 +-------------------------------------------------+ 189 Ss | DWDM Network Elements | Rs 190 +---+ | | | \ / | | | +--+ 191 Tx L1----|->| \ +------+ +------+ / |--|-->Rx L1 192 +---+ | | | | | +------+ | | | | | +--+ 193 +---+ | | | | | | | | | | | | +--+ 194 Tx L2----|->| OM |-->|------|->| OADM |--|------|->| OD |--|-->Rx L2 195 +---+ | | | | | | | | | | | | +--+ 196 +---+ | | | | | +------+ | | | | | +--+ 197 Tx L3----|->| / | DWDM | | ^ | DWDM | \ |--|-->Rx L3 198 +---+ | | / | Link +----|--|----+ Link | \ | | +--+ 199 +-----------+ | | +----------+ 200 +--+ +--+ 201 | | 202 Rs v | Ss 203 +-----+ +-----+ 204 |RxLx | |TxLx | 205 +-----+ +-----+ 206 Ss = reference point at the DWDM network element tributary output 207 Rs = reference point at the DWDM network element tributary input 208 Lx = Lambda x 209 OM = Optical Mux 210 OD = Optical Demux 211 OADM = Optical Add Drop Mux 213 from Fig. 5.1/G.698.2 215 Figure 1: Linear Black Link 217 G.698.2 [ITU.G698.2] defines also Ring Black Link configurations 218 [Fig. 5.2/G.698.2] and Bidirectional Black Link configurations [Fig. 219 5.3/G.698.2] 221 4.1. Optical Parameters Description 223 The black links are managed at the edges, i.e. at the transmitters 224 (Tx) and receivers (Rx) attached to the S and R reference points 225 respectively. The parameters that could be managed at the black link 226 edges are specified in G.698.2 [ITU.G698.2] section 5.3 referring the 227 "application code" notation 229 The definitions of the optical parameters are provided below to 230 increase the readability of the document, where the definition is 231 ended by (G) the parameter can be retrieve with a GET, when (S) it 232 can be provisioned by a SET, (G,S) can be either GET and SET. 234 To support the management of these parameters, the SNMP MIB in RFC 235 3591 [RFC3591] is extended with a new MIB module defined in section 6 236 of this document. This new MIB module includes the definition of new 237 configuration table of the OCh Layer for the parameters at Tx (S) and 238 Rx (R). 240 4.1.1. Rs-Ss Configuration 242 The Rs-Ss configuration table allows configuration of Wavelength, 243 Power and Application codes as described in [ITU.G698.2] and G.694.1 244 [ITU.G694.1] 245 This parameter report the current Transceiver Output power, it can be 246 either a setting and measured value (G, S) NEED TO DISCUSS ON THIS. 248 Wavelength Value (see G.694.1 Table 1): 249 This parameter indicates the wavelength value that Ss and Rs will 250 be set to work (in THz) se in particular Section 6/G.694.1 (G, S). 252 Vendor Transceiver Class: 253 Other than specifying all the Transceiver parameter, it might be 254 convenient for the vendors to summarize a set of parameters in a 255 single proprietary parameter: the Class of transceiver. The 256 Transceiver classification will be based on the Vendor Name and 257 the main TX and RX parameters (i.e. Trunk Mode, Framing, Bit rate, 258 Trunk Type, Channel Band, Channel Grid, Modulation Format, Channel 259 Modulation Format, FEC Coding, Electrical Signal Framing at Tx, 260 Minimum maximum Chromatic Disperion (CD) at Rx, Maximum 261 Polarization Mode Dispersion (PMD) at Rx, Maximum differential 262 group delay at Rx, Loopbacks, TDC, Pre-FEC BER, Q-factor, 263 Q-margin,etc.). If this parameter is used, the MIB parameters 264 specifying the Transceiver characteristics may not be significant 265 and the vendor will be responsible to specify the Class contents 266 and values. The Vendor can publish the parameters of its Classes 267 or declare to be compatible with published Classes.(G) Optional 268 for compliance. (not mentioned in G.698) 270 Number of Vendor Transceiver Class Supported 271 This parameter indicates the number of Vendor Transceiver codes 272 supported by this interface (G). 274 Single-channel application codes (see G.698.2): 275 This parameter indicates the transceiver application code at Ss 276 and Rs as defined in [ITU.G698.2] Chapter 5.4 - this parameter can 277 be called Optical Interface Identifier OII as per [draft- 278 martinelli-wson-interface-class] (G). 280 Number of Single-channel application codes Supported 281 This parameter indicates the number of Single-channel application 282 codes supported by this interface (G). 284 Current Laser Output power: 285 This parameter report the current Transceiver Output power, it can 286 be either a setting and measured value (G, S). 288 Minimum Laser Output power: 289 This parameter report the minimum Transceiver Output power 290 supported by this interface (G). 292 Maximum Laser Output power: 293 This parameter report the maximum Transceiver Output power 294 supported by this interface (G). 296 Current Laser Input power: 297 This parameter report the current Transceiver Input power (G). 299 Minimum Laser Intput power: 300 This parameter report the minimum Transceiver Input power 301 supported by this interface (G). 303 Maximum Laser Intput power: 304 This parameter report the maximum Transceiver Input power 305 supported by this interface (G). 307 +--------------------------------------+-----------+----------------+ 308 | PARAMETERS | Get/Set | Reference | 309 +--------------------------------------+-----------+----------------+ 310 | Wavelength Value | G,S | G.694.1 S.6 | 311 | Vendor Transceiver Class | G | N.A. | 312 | Number of Vendor Transceiver Class | G | N.A. | 313 | Supported | | | 314 | Single-channel application codes | G | G.698.2 S.5.3 | 315 | Number of Single-channel application | G | N.A. | 316 | codes Supported | | | 317 | Current Output Power | G,S | N.A. | 318 | Minimum Output Power | G | N.A. | 319 | Maximum Output Power | G | N.A. | 320 | Current Input Power | G | N.A. | 321 | Minimum Input Power | G | N.A. | 322 | Maximum Input Power | G | N.A. | 323 +--------------------------------------+-----------+----------------+ 325 Table 1: Rs-Ss Configuration 327 4.1.2. Table of Application Codes 328 This table has a list of Application codes supported by this 329 interface at point R are defined in G.698.2. 331 4.1.2.1. 333 Maximum and minimum mean input power: 334 The maximum and minimum values of the average received power (in 335 dBm) at point Rs. (G) 337 +-------------------------------+---------+-----------------+ 338 | PARAMETERS | Get/Set | Reference | 339 +-------------------------------+---------+-----------------+ 340 | MAX and min mean input power | G | G.698.2 S.7.4.1 | 341 +-------------------------------+---------+-----------------+ 343 Table 2: mandatory parameters 345 4.2. Use of ifTable 347 This section specifies how the MIB II interfaces group, as defined in 348 RFC 2863 [RFC2863], is used for the link ends of a black link. Only 349 the ifGeneralInformationGroup will be supported for the ifTable and 350 the ifStackTable to maintain the relationship between the OCh and OPS 351 layers. The OCh and OPS layers are managed in the ifTable using 352 IfEntries that correlate to the layers depicted in Figure 1. 354 For example, a device with TX and/or RX will have an Optical Physical 355 Section (OPS) layer, and an Optical Channel (OCh) layer. There is a 356 one to n relationship between the OPS and OCh layers. 358 EDITOR NOTE: Reason for changing from OChr to OCh: Work on revised 359 G.872 in the SG15 December 2011 meeting agreed to remove OChr from 360 the architecture and to update G.709 to account for this 361 architectural change. The meeting also agreed to consent the revised 362 text of G.872 and G.709 at the September 2012 SG15 meeting. 364 Figure 2 In the following figures, opticalChannel and 365 opticalPhysicalSection are abbreviated as och and ops respectively. 367 _____________________ 368 \ 369 Path Data Unit |\ 370 (ODUk) | \ 371 _____________________| \ __________________ 372 | | | > 373 Tandem Data Unit | | | | 374 (ODUkT) | | OCh Layer | > n och IfEntries 375 _____________________| | | | 376 | |__________________| > 377 Optical | /| | > 378 Transport Unit | / | | | 379 (OTUk) |/ | OPSn Layer | > m ops IfEntries 380 _____________________/ | | | 381 |__________________| > 382 Sub-layers in 383 the OCh Layer 385 Figure 2: OTN Layers for OPS and OCh 387 Each opticalChannel IfEntry is mapped to one of the m 388 opticalPhysicalSection IfEntries, where m is greater than or equal to 389 1. Conversely, each opticalTransPhysicalSection port entry is mapped 390 to one of the n opticalChannel IfEntries, where n is greater than or 391 equal to 1. 393 The design of the Optical Interface MIB provides the option to model 394 an interface either as a single bidirectional object containing both 395 sink and source functions or as a pair of unidirectional objects, one 396 containing sink functions and the other containing source functions. 398 If the sink and source for a given protocol layer are to be modelled 399 as separate objects, then there need to be two ifTable entries, one 400 that corresponds to the sink and one that corresponds to the source, 401 where the directionality information is provided in the configuration 402 tables for that layer via the associated Directionality objects. The 403 agent is expected to maintain consistent directionality values 404 between ifStackTable layers (e.g., a sink must not be stacked in a 405 1:1 manner on top of a source, or vice-versa), and all protocol 406 layers that are represented by a given ifTable entry are expected to 407 have the same directionality. 409 When separate ifTable entries are used for the source and sink 410 functions of a given physical interface, association between the two 411 uni-directional ifTable entries (one for the source function and the 412 other for the sink functions) should be provided. It is recommended 413 that identical ifName values are used for the two ifTable entries to 414 indicate such association. An implementation shall explicitly state 415 what mechanism is used to indicate the association, if ifName is not 416 used. 418 4.2.1. Use of ifTable for OPS Layer 420 Only the ifGeneralInformationGroup needs to be supported. 422 ifTable Object Use for OTN OPS Layer 423 ===================================================================== 425 ifIndex The interface index. 427 ifDescr Optical Transport Network (OTN) Optical 428 Physical Section (OPS) 430 ifType opticalPhysicalSection (xxx) 432 <<>> 434 ifSpeed Actual bandwidth of the interface in bits per 435 second. If the bandwidth of the interface is 436 greater than the maximum value of 4,294,967,295, 437 then the maximum value is reported and 438 ifHighSpeed must be used to report the 439 interface's speed. 441 ifPhysAddress An octet string with zero length. (There is 442 no specific address associated with the 443 interface.) 445 ifAdminStatus The desired administrative state of the 446 interface. Supports read-only access. 448 ifOperStatus The operational state of the interface. The 449 value lowerLayerDown(7) is not used, since 450 there is no lower layer interface. This object 451 is set to notPresent(6) if a component is 452 missing, otherwise it is set to down(2) if 453 either of the objects optIfOPSnCurrentStatus 454 indicates that any defect is present. 456 ifLastChange The value of sysUpTime at the last change in 457 ifOperStatus. 459 ifName Enterprise-specific convention (e.g., TL-1 AID) 460 to identify the physical or data entity 461 associated with this interface or an 462 OCTET STRING of zero length. The 463 enterprise-specific convention is intended to 464 provide the means to reference one or more 465 enterprise-specific tables. 467 ifLinkUpDownTrapEnable Default value is enabled(1). Supports 468 read-only access. 470 ifHighSpeed Actual bandwidth of the interface in Mega-bits 471 per second. A value of n represents a range of 472 'n-0.5' to 'n+0.499999'. 474 ifConnectorPresent Set to true(1). 476 ifAlias The (non-volatile) alias name for this interface 477 as assigned by the network manager. 479 4.2.2. Use of ifTable for OCh Layer 481 Use of ifTable for OCh Layer See RFC 3591 [RFC3591] section 2.4 483 4.2.3. Use of ifStackTable 485 Use of the ifStackTable and ifInvStackTable to associate the 486 opticalPhysicalSection and opticalChannel interface entries is best 487 illustrated by the example shown in Figure 3. The example assumes an 488 ops interface with ifIndex i that carries two multiplexed OCh 489 interfaces with ifIndex values of j and k, respectively. The example 490 shows that j and k are stacked above (i.e., multiplexed into) i. 491 Furthermore, it shows that there is no layer lower than i and no 492 layer higher than j and/or k. 494 Figure 3 496 HigherLayer LowerLayer 497 -------------------------- 498 0 j 499 0 k 500 j i 501 k i 502 i 0 504 Figure 3: Use of ifStackTable for an OTN port 506 For the inverse stack table, it provides the same information as the 507 interface stack table, with the order of the Higher and Lower layer 508 interfaces reversed. 510 5. Structure of the MIB Module 512 EDITOR NOTE:text will be provided based on the MIB module in 513 Section 6 515 6. Object Definitions 517 EDITOR NOTE: Once the scope in Section 1 and the parameters in 518 Section 4 are finalized, a MIB module will be defined. It could be 519 an extension to the OPT-IF-MIB module of RFC 3591. >>> 521 OPT-IF-698-MIB DEFINITIONS ::= BEGIN 523 IMPORTS 524 MODULE-IDENTITY, 525 OBJECT-TYPE, 526 Gauge32, 527 Integer32, 528 Unsigned32, 529 Counter64, 530 transmission, 531 NOTIFICATION-TYPE 532 FROM SNMPv2-SMI 533 TEXTUAL-CONVENTION, 534 RowPointer, 535 RowStatus, 536 TruthValue, 537 DisplayString, 538 DateAndTime 539 FROM SNMPv2-TC 540 SnmpAdminString 541 FROM SNMP-FRAMEWORK-MIB 542 MODULE-COMPLIANCE, OBJECT-GROUP 543 FROM SNMPv2-CONF 544 ifIndex 545 FROM IF-MIB 546 optIfMibModule 547 FROM OPT-IF-MIB; 549 -- This is the MIB module for the optical parameters - 550 -- Application codes associated with the black link end points. 552 optIfXcvrMibModule MODULE-IDENTITY 553 LAST-UPDATED "201204250000Z" 554 ORGANIZATION "IETF Ops/Camp MIB Working Group" 555 CONTACT-INFO 556 "WG charter: 557 http://www.ietf.org/html.charters/ 559 Mailing Lists: 560 Editor: Gabriele Galimberti 561 Email: ggalimbe@cisco.com" 562 DESCRIPTION 563 "The MIB module to describe Black Link tranceiver 564 characteristics to rfc3591. 565 Copyright (C) The Internet Society (2012). This version 566 of this MIB module is part of ; see the RFC 567 itself for full legal notices." 568 REVISION "201305050000Z" 569 DESCRIPTION 570 "Draft version 1.0" 571 REVISION "201305050000Z" 572 DESCRIPTION 573 "Draft version 2.0" 574 REVISION "201302270000Z" 575 DESCRIPTION 576 "Draft version 3.0" 577 REVISION "201307020000Z" 578 DESCRIPTION 579 "Mib has in application code/vendor transcievercode G.698." 580 ::= { optIfMibModule 4 } 582 -- Addition to the RFC 3591 objects 583 optIfOChSsRsGroup OBJECT IDENTIFIER ::= { optIfXcvrMibModule 1 } 585 -- OCh Ss/Rs config table 586 -- The application code/vendor tranceiver class for the Black Link 587 -- Ss-Rs will be added to the OchConfigTable 589 optIfOChSsRsConfigTable OBJECT-TYPE 590 SYNTAX SEQUENCE OF OptIfOChSsRsConfigEntry 591 MAX-ACCESS not-accessible 592 STATUS current 593 DESCRIPTION 594 "A table of Och General config extension parameters" 595 ::= { optIfOChSsRsGroup 1 } 597 optIfOChSsRsConfigEntry OBJECT-TYPE 598 SYNTAX OptIfOChSsRsConfigEntry 599 MAX-ACCESS not-accessible 600 STATUS current 601 DESCRIPTION 602 "A conceptual row that contains G.698 parameters for an 603 interface." 604 INDEX { ifIndex } 605 ::= { optIfOChSsRsConfigTable 1 } 607 OptIfOChSsRsConfigEntry ::= 608 SEQUENCE { 609 optIfOChWavelengthn Unsigned32, 610 optIfOChInterfaceVendorTransceiverClass DisplayString, 611 optIfOChNumberVendorClassesSupported Unsigned32, 612 optIfOChInterfaceApplicationCode DisplayString, 613 optIfOChNumberApplicationCodesSupported Unsigned32, 614 optIfOChOutputPower Integer32, 615 optIfOChMinOutputPower Integer32, 616 optIfOChMaxOutputPower Integer32, 617 optIfOChInputPower Integer32, 618 optIfOChMinInputPower Integer32, 619 optIfOChMaxInputPower Integer32 621 } 623 optIfOChWavelengthn OBJECT-TYPE 624 SYNTAX Unsigned32 625 MAX-ACCESS read-write 626 STATUS current 627 DESCRIPTION 628 " This parameter indicate minimum wavelength spectrum - n, in 629 a definite wavelength Band (L, C and S) as represented in 630 [RFC6205] by the formula - 631 Wavelength (nm ) = 1471nm + n* optIfOChMiminumChannelSpacing 632 (converted to nm) 633 Eg - optIfOChMiminumChannelSpacing in nm 634 'Wavelength (nm ) = 1471nm + n* 20nm (20nm is the spacing 635 for CWDM)' 636 " 637 ::= { optIfOChSsRsConfigEntry 1 } 639 optIfOChInterfaceVendorTransceiverClass OBJECT-TYPE 640 SYNTAX DisplayString 641 MAX-ACCESS read-write 642 STATUS current 643 DESCRIPTION 644 "As defined in G.698 645 Vendors can summarize a set of parameters in a 646 single proprietary parameter: the Class of transceiver. The 647 Transceiver classification will be based on the Vendor Name 648 and the main TX and RX parameters (i.e. Trunk Mode, Framing, 649 Bit rate, Trunk Type etc). 650 This defines the tranceiver class that is/should be used by 651 this interface. The optIfOChSrcVendorTranscieverClassTable 652 has all the vendor classes supported by this interface." 654 ::= { optIfOChSsRsConfigEntry 2 } 656 optIfOChNumberVendorClassesSupported OBJECT-TYPE 657 SYNTAX Unsigned32 658 MAX-ACCESS read-only 659 STATUS current 660 DESCRIPTION 661 " Number of Vedor classes supported by this interface." 662 ::= { optIfOChSsRsConfigEntry 3 } 664 optIfOChInterfaceApplicationCode OBJECT-TYPE 665 SYNTAX DisplayString 666 MAX-ACCESS read-write 667 STATUS current 668 DESCRIPTION 669 "This parameter indicates the transceiver application code at 670 Ss and Rs as defined in [ITU.G698.2] Chapter 5.3, that 671 is/should be used by this interface. The 672 optIfOChSrcApplicationCodeTable has all the application 673 codes supported by this interface. " 674 ::= { optIfOChSsRsConfigEntry 4 } 676 optIfOChNumberApplicationCodesSupported OBJECT-TYPE 677 SYNTAX Unsigned32 678 MAX-ACCESS read-only 679 STATUS current 680 DESCRIPTION 681 " Number of Application codes supported by this interface." 682 ::= { optIfOChSsRsConfigEntry 5 } 684 optIfOChOutputPower OBJECT-TYPE 685 SYNTAX Integer32 686 UNITS "0.01dbm" 687 MAX-ACCESS read-write 688 STATUS current 689 DESCRIPTION 690 " The output power for this interface in .01 dbm " 691 ::= { optIfOChSsRsConfigEntry 6 } 693 optIfOChMinOutputPower OBJECT-TYPE 694 SYNTAX Integer32 695 UNITS "0.01dbm" 696 MAX-ACCESS read-only 697 STATUS current 698 DESCRIPTION 699 " The minimum output power for this interface in .01 dbm " 700 ::= { optIfOChSsRsConfigEntry 7 } 702 optIfOChInputPower OBJECT-TYPE 703 SYNTAX Integer32 704 UNITS "0.01dbm" 705 MAX-ACCESS read-only 706 STATUS current 707 DESCRIPTION 708 " The input power for this interface in .01 dbm " 709 ::= { optIfOChSsRsConfigEntry 8 } 711 optIfOChMinInputPower OBJECT-TYPE 712 SYNTAX Integer32 713 UNITS "0.01dbm" 714 MAX-ACCESS read-only 715 STATUS current 716 DESCRIPTION 717 " The minimum input power for this interface in .01 dbm " 718 ::= { optIfOChSsRsConfigEntry 9 } 720 optIfOChMaxInputPower OBJECT-TYPE 721 SYNTAX Integer32 722 UNITS "0.01dbm" 723 MAX-ACCESS read-only 724 STATUS current 725 DESCRIPTION 726 " The maximum input power for this interface in .01 dbm " 727 ::= { optIfOChSsRsConfigEntry 10 } 729 -- Table of Application codes supported by the interface 730 -- OptIfOChSrcApplicationCodeEntry 732 optIfOChSrcApplicationCodeTable OBJECT-TYPE 733 SYNTAX SEQUENCE OF OptIfOChSrcApplicationCodeEntry 734 MAX-ACCESS not-accessible 735 STATUS current 736 DESCRIPTION 737 "A Table of Application codes supported by this interface." 738 ::= { optIfOChSsRsGroup 2 } 740 optIfOChSrcApplicationCodeEntry OBJECT-TYPE 741 SYNTAX OptIfOChSrcApplicationCodeEntry 742 MAX-ACCESS not-accessible 743 STATUS current 744 DESCRIPTION 745 "A conceptual row that contains the Application code for this 746 interface." 747 INDEX { ifIndex, optIfOChApplicationCodeNumber } 748 ::= { optIfOChSrcApplicationCodeTable 1 } 750 OptIfOChSrcApplicationCodeEntry ::= 751 SEQUENCE { 752 optIfOChApplicationCodeNumber Integer32, 753 optIfOChApplicationCode DisplayString 754 } 756 optIfOChApplicationCodeNumber OBJECT-TYPE 757 SYNTAX Integer32 (1..255) 758 MAX-ACCESS not-accessible 759 STATUS current 760 DESCRIPTION 761 " The number of the application code supported at this 762 interface. The interface can support more than one 763 application codes. 765 " 766 ::= { optIfOChSrcApplicationCodeEntry 1} 768 optIfOChApplicationCode OBJECT-TYPE 769 SYNTAX DisplayString 770 MAX-ACCESS read-only 771 STATUS current 772 DESCRIPTION 773 " The application code supported by this interface DWDM 774 link." 775 ::= { optIfOChSrcApplicationCodeEntry 2} 777 -- Table of Vendor Transceiver class supported by the interface 778 -- OptIfOChSrcVendorTranscieverClassEntry 780 optIfOChSrcVendorTranscieverClassTable OBJECT-TYPE 781 SYNTAX SEQUENCE OF OptIfOChSrcVendorTranscieverClassEntry 782 MAX-ACCESS not-accessible 783 STATUS current 784 DESCRIPTION 785 "A table of OCh Src (Ss) tranceiver classes supported by 786 this interface." 787 ::= { optIfOChSsRsGroup 3 } 789 optIfOChSrcVendorTranscieverClassEntry OBJECT-TYPE 790 SYNTAX OptIfOChSrcVendorTranscieverClassEntry 791 MAX-ACCESS not-accessible 792 STATUS current 793 DESCRIPTION 794 "A conceptual row that contains the tranceiver classes 795 supported by this interface." 796 INDEX { ifIndex, optIfOChTranscieverClassNumber } 797 ::= { optIfOChSrcVendorTranscieverClassTable 1 } 799 OptIfOChSrcVendorTranscieverClassEntry ::= 800 SEQUENCE { 801 optIfOChTranscieverClassNumber Integer32, 802 optIfOChTranscieverClass DisplayString 803 } 805 optIfOChTranscieverClassNumber OBJECT-TYPE 806 SYNTAX Integer32 (1..255) 807 MAX-ACCESS not-accessible 808 STATUS current 809 DESCRIPTION 810 " The number of the application code supported at this 811 interface. The interface can support more than one 812 application codes. 814 " 815 ::= { optIfOChSrcVendorTranscieverClassEntry 1} 817 optIfOChTranscieverClass OBJECT-TYPE 818 SYNTAX DisplayString 819 MAX-ACCESS read-only 820 STATUS current 821 DESCRIPTION 822 " Vendor tranceiver class supported by this interface." 823 ::= { optIfOChSrcVendorTranscieverClassEntry 2} 825 END 827 7. Relationship to Other MIB Modules 829 7.1. Relationship to the [TEMPLATE TODO] MIB 831 7.2. MIB modules required for IMPORTS 833 8. Definitions 835 [TEMPLATE TODO]: put your valid MIB module here. 836 A list of tools that can help automate the process of 837 checking MIB definitions can be found at 838 http://www.ops.ietf.org/mib-review-tools.html 840 9. Security Considerations 842 There are a number of management objects defined in this MIB module 843 with a MAX-ACCESS clause of read-write and/or read-create. Such 844 objects may be considered sensitive or vulnerable in some network 845 environments. The support for SET operations in a non-secure 846 environment without proper protection can have a negative effect on 847 network operations. These are the tables and objects and their 848 sensitivity/vulnerability: 850 Some of the readable objects in this MIB module (i.e., objects with a 851 MAX-ACCESS other than not-accessible) may be considered sensitive or 852 vulnerable in some network environments. It is thus important to 853 control even GET and/or NOTIFY access to these objects and possibly 854 to even encrypt the values of these objects when sending them over 855 the network via SNMP. 857 SNMP versions prior to SNMPv3 did not include adequate security. 858 Even if the network itself is secure (for example by using IPsec), 859 even then, there is no control as to who on the secure network is 860 allowed to access and GET/SET (read/change/create/delete) the objects 861 in this MIB module. 863 It is RECOMMENDED that implementers consider the security features as 864 provided by the SNMPv3 framework (see [RFC3410], section 8), 865 including full support for the SNMPv3 cryptographic mechanisms (for 866 authentication and privacy). 868 Further, deployment of SNMP versions prior to SNMPv3 is NOT 869 RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to 870 enable cryptographic security. It is then a customer/operator 871 responsibility to ensure that the SNMP entity giving access to an 872 instance of this MIB module is properly configured to give access to 873 the objects only to those principals (users) that have legitimate 874 rights to indeed GET or SET (change/create/delete) them. 876 10. IANA Considerations 878 Option #1: 880 The MIB module in this document uses the following IANA-assigned 881 OBJECT IDENTIFIER values recorded in the SMI Numbers registry: 883 Descriptor OBJECT IDENTIFIER value 884 ---------- ----------------------- 886 sampleMIB { mib-2 XXX } 888 Option #2: 890 Editor's Note (to be removed prior to publication): the IANA is 891 requested to assign a value for "XXX" under the 'mib-2' subtree and 892 to record the assignment in the SMI Numbers registry. When the 893 assignment has been made, the RFC Editor is asked to replace "XXX" 894 (here and in the MIB module) with the assigned value and to remove 895 this note. 897 Note well: prior to official assignment by the IANA, an internet 898 draft MUST use placeholders (such as "XXX" above) rather than actual 899 numbers. See RFC4181 Section 4.5 for an example of how this is done 900 in an internet draft MIB module. 902 Option #3: 904 This memo includes no request to IANA. 906 11. Contributors 908 Arnold Mattheus 909 Deutsche Telekom 910 Darmstadt 911 Germany 912 email a.mattheus@telekom.de 914 Manuel Paul 915 Deutsche Telekom 916 Berlin 917 Germany 918 email Manuel.Paul@telekom.de 920 Frank Luennemann 921 Deutsche Telekom 922 Munster 923 Germany 924 email Frank.Luennemann@telekom.de 926 Scott Mansfield 927 Ericsson Inc. 928 email scott.mansfield@ericsson.com 930 Najam Saquib 931 Cisco 932 Ludwig-Erhard-Strasse 3 933 ESCHBORN, HESSEN 65760 934 GERMANY 935 email nasaquib@cisco.com 937 Walid Wakim 938 Cisco 939 9501 Technology Blvd 940 ROSEMONT, ILLINOIS 60018 941 UNITED STATES 942 email wwakim@cisco.com 944 Ori Gerstel 945 Cisco 946 32 HaMelacha St., (HaSharon Bldg) 947 SOUTH NETANYA, HAMERKAZ 42504 948 ISRAEL 949 email ogerstel@cisco.com 951 12. References 952 12.1. Normative References 954 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group 955 MIB", RFC 2863, June 2000. 957 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 958 Requirement Levels", BCP 14, RFC 2119, March 1997. 960 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 961 Schoenwaelder, Ed., "Structure of Management Information 962 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 964 [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. 965 Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD 966 58, RFC 2579, April 1999. 968 [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, 969 "Conformance Statements for SMIv2", STD 58, RFC 2580, 970 April 1999. 972 [RFC3591] Lam, H-K., Stewart, M., and A. Huynh, "Definitions of 973 Managed Objects for the Optical Interface Type", RFC 3591, 974 September 2003. 976 [RFC6205] Otani, T. and D. Li, "Generalized Labels for Lambda- 977 Switch-Capable (LSC) Label Switching Routers", RFC 6205, 978 March 2011. 980 [ITU.G698.2] 981 International Telecommunications Union, "Amplified 982 multichannel dense wavelength division multiplexing 983 applications with single channel optical interfaces ", 984 ITU-T Recommendation G.698.2, November 2009. 986 [ITU.G709] 987 International Telecommunications Union, "Interface for the 988 Optical Transport Network (OTN) ", ITU-T Recommendation 989 G.709, March 2003. 991 [ITU.G872] 992 International Telecommunications Union, "Architecture of 993 optical transport networks ", ITU-T Recommendation G.872, 994 November 2001. 996 [ITU.G798] 997 International Telecommunications Union, "Characteristics 998 of optical transport network hierarchy equipment 999 functional blocks ", ITU-T Recommendation G.798, October 1000 2010. 1002 [ITU.G874] 1003 International Telecommunications Union, "Management 1004 aspects of optical transport network elements ", ITU-T 1005 Recommendation G.874, July 2010. 1007 [ITU.G874.1] 1008 International Telecommunications Union, "Optical transport 1009 network (OTN): Protocol-neutral management information 1010 model for the network element view ", ITU-T Recommendation 1011 G.874.1, January 2002. 1013 [ITU.G959.1] 1014 International Telecommunications Union, "Optical transport 1015 network physical layer interfaces ", ITU-T Recommendation 1016 G.959.1, November 2009. 1018 [ITU.G826] 1019 International Telecommunications Union, "End-to-end error 1020 performance parameters and objectives for international, 1021 constant bit-rate digital paths and connections ", ITU-T 1022 Recommendation G.826, November 2009. 1024 [ITU.G8201] 1025 International Telecommunications Union, "Error performance 1026 parameters and objectives for multi-operator international 1027 paths within the Optical Transport Network (OTN) ", ITU-T 1028 Recommendation G.8201, April 2011. 1030 [ITU.G694.1] 1031 International Telecommunications Union, "Spectral grids 1032 for WDM applications: DWDM frequency grid ", ITU-T 1033 Recommendation G.694.1, June 2002. 1035 [ITU.G7710] 1036 International Telecommunications Union, "Common equipment 1037 management function requirements ", ITU-T Recommendation 1038 G.7710, May 2008. 1040 12.2. Informative References 1042 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 1043 "Introduction and Applicability Statements for Internet- 1044 Standard Management Framework", RFC 3410, December 2002. 1046 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 1047 June 1999. 1049 [RFC4181] Heard, C., "Guidelines for Authors and Reviewers of MIB 1050 Documents", BCP 111, RFC 4181, September 2005. 1052 [I-D.kunze-g-698-2-management-control-framework] 1053 Kunze, R., "A framework for Management and Control of 1054 optical interfaces supporting G.698.2", draft- 1055 kunze-g-698-2-management-control-framework-00 (work in 1056 progress), July 2011. 1058 [RFC4054] Strand, J. and A. Chiu, "Impairments and Other Constraints 1059 on Optical Layer Routing", RFC 4054, May 2005. 1061 Appendix A. Change Log 1063 This optional section should be removed before the internet draft is 1064 submitted to the IESG for publication as an RFC. 1066 Note to RFC Editor: please remove this appendix before publication as 1067 an RFC. 1069 Appendix B. Open Issues 1071 Note to RFC Editor: please remove this appendix before publication as 1072 an RFC. 1074 Authors' Addresses 1076 Gabriele Galimberti (editor) 1077 Cisco 1078 Via Philips,12 1079 20052 - Monza 1080 Italy 1082 Phone: +390392091462 1083 Email: ggalimbe@cisco.com 1084 Ruediger Kunze (editor) 1085 Deutsche Telekom 1086 Dddd, xx 1087 Berlin 1088 Germany 1090 Phone: +49xxxxxxxxxx 1091 Email: RKunze@telekom.de 1093 Hing-Kam Lam (editor) 1094 Alcatel-Lucent 1095 600-700 Mountain Avenue, Murray Hill 1096 New Jersey, 07974 1097 USA 1099 Phone: +17323313476 1100 Email: kam.lam@alcatel-lucent.com 1102 Dharini Hiremagalur (editor) 1103 Juniper 1104 1194 N Mathilda Avenue 1105 Sunnyvale - 94089 California 1106 USA 1108 Phone: +1408 1109 Email: dharinih@juniper.net