idnits 2.17.1 draft-galikunze-ccamp-g-698-2-snmp-mib-11.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 21, 2015) is 3321 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 133, but not defined == Missing Reference: 'TEMPLATE TODO' is mentioned on line 788, but not defined == Unused Reference: 'RFC6205' is defined on line 929, but no explicit reference was found in the text == Unused Reference: 'ITU.G709' is defined on line 939, but no explicit reference was found in the text == Unused Reference: 'ITU.G959.1' is defined on line 966, but no explicit reference was found in the text == Unused Reference: 'ITU.G826' is defined on line 971, but no explicit reference was found in the text == Unused Reference: 'ITU.G8201' is defined on line 977, but no explicit reference was found in the text == Unused Reference: 'ITU.G7710' is defined on line 988, but no explicit reference was found in the text == Unused Reference: 'RFC2629' is defined on line 999, but no explicit reference was found in the text == Unused Reference: 'RFC4181' is defined on line 1002, but no explicit reference was found in the text == Unused Reference: 'I-D.kunze-g-698-2-management-control-framework' is defined on line 1005, 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: September 22, 2015 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 21, 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-11 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 22, 2015. 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. Optical Parameters Description . . . . . . . . . . . . . 6 82 4.1.1. Rs-Ss Configuration . . . . . . . . . . . . . . . . . 6 83 4.1.2. Table of Application Identifiers . . . . . . . . . . 7 84 4.2. Use of ifTable . . . . . . . . . . . . . . . . . . . . . 8 85 4.2.1. Use of ifTable for OPS Layer . . . . . . . . . . . . 9 86 4.2.2. Use of ifTable for OCh Layer . . . . . . . . . . . . 10 87 4.2.3. Use of ifStackTable . . . . . . . . . . . . . . . . . 10 88 5. Structure of the MIB Module . . . . . . . . . . . . . . . . . 11 89 6. Object Definitions . . . . . . . . . . . . . . . . . . . . . 11 90 7. Relationship to Other MIB Modules . . . . . . . . . . . . . . 18 91 7.1. Relationship to the [TEMPLATE TODO] MIB . . . . . . . . . 18 92 7.2. MIB modules required for IMPORTS . . . . . . . . . . . . 18 93 8. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 18 94 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 95 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 96 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19 97 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 98 12.1. Normative References . . . . . . . . . . . . . . . . . . 20 99 12.2. Informative References . . . . . . . . . . . . . . . . . 22 100 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 23 101 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 23 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 104 1. Introduction 106 This memo defines a portion of the Management Information Base (MIB) 107 used by Simple Network Management Protocol (SNMP)in TCP/IP-based 108 internets. In particular, it defines objects for managing single 109 channel optical interface parameters of DWDM applications, using the 110 approach specified in G.698.2. This RFC is an extension of RFC3591 111 to support the optical parameters specified in ITU-T G.698.2 112 [ITU.G698.2] and application identifiers specified in ITU-T G.874.1 113 [ITU.G874.1] . Note that G.874.1 encompasses vendor-specific codes, 114 which if used would make the interface a single vendor IaDI and could 115 still be managed. 117 The Black Link approach allows supporting an optical transmitter/ 118 receiver pair of one vendor to inject an optical tributary signal and 119 run it over an optical network composed of amplifiers, filters, add- 120 drop multiplexers from a different vendor. In the OTN architecture, 121 the 'black-link' represents a pre-certified network media channel 122 conforming to G.698.2 specifications at the S and R reference points. 124 [Editor's note: In G.698.2 this corresponds to the optical path from 125 point S to R; network media channel is also used and explained in 126 draft-ietf-ccamp-flexi-grid-fwk-02] 128 Management will be performed at the edges of the network media 129 channel (i.e., at the transmitters and receivers attached to the S 130 and R reference points respectively) for the relevant parameters 131 specified in G.698.2 [ITU.G698.2], G.798 [ITU.G798], G.874 132 [ITU.G874], and the performance parameters specified in G.7710/Y.1701 133 [ITU-T G.7710] and G.874.1 [ITU.G874.1]. 135 G.698.2 [ITU.G698.2] is primarily intended for metro applications 136 that include optical amplifiers. Applications are defined in G.698.2 137 [ITU.G698.2] using optical interface parameters at the single-channel 138 connection points between optical transmitters and the optical 139 multiplexer, as well as between optical receivers and the optical 140 demultiplexer in the DWDM system. This Recommendation uses a 141 methodology which does not explicitly specify the details of the 142 optical network between reference point Ss and Rs, e.g., the passive 143 and active elements or details of the design. The Recommendation 144 currently includes unidirectional DWDM applications at 2.5 and 10 145 Gbit/s (with 100 GHz and 50 GHz channel frequency spacing). Work is 146 still under way for 40 and 100 Gbit/s interfaces. There is 147 possibility for extensions to a lower channel frequency spacing. 148 This document specifically refers to the "application code" defined 149 in the G.698.2 [ITU.G698.2] and included in the Application 150 Identifier defined in G.874.1 [ITU.G874.1] and G.872 [ITU.G872], plus 151 a few optical parameters not included in the G.698.2 application code 152 specification. 154 This draft refers and supports also the draft-kunze-g-698-2- 155 management-control-framework 157 The building of an SNMP MIB describing the optical parameters defined 158 in G.698.2 [ITU.G698.2], and reflected in G.874.1 [ITU.G874], allows 159 the different vendors and operator to retrieve, provision and 160 exchange information across the G.698.2 multi-vendor IaDI in a 161 standardized way. 163 The MIB, reporting the Optical parameters and their values, 164 characterizes the features and the performances of the optical 165 components and allow a reliable black link design in case of multi 166 vendor optical networks. 168 Although RFC 3591 [RFC3591] describes and defines the SNMP MIB of a 169 number of key optical parameters, alarms and Performance Monitoring, 170 as this RFC is over a decade old, it is primarily pre-OTN, and a more 171 complete and up-to-date description of optical parameters and 172 processes can be found in the relevant ITU-T Recommendations. The 173 same considerations can be applied to the RFC 4054 [RFC4054] 175 2. The Internet-Standard Management Framework 177 For a detailed overview of the documents that describe the current 178 Internet-Standard Management Framework, please refer to section 7 of 179 RFC 3410 [RFC3410]. 181 Managed objects are accessed via a virtual information store, termed 182 the Management Information Base or MIB. MIB objects are generally 183 accessed through the Simple Network Management Protocol (SNMP). 184 Objects in the MIB are defined using the mechanisms defined in the 185 Structure of Management Information (SMI). This memo specifies a MIB 186 module that is compliant to the SMIv2, which is described in STD 58, 187 RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 188 [RFC2580]. 190 3. Conventions 192 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 193 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 194 document are to be interpreted as described in RFC 2119 [RFC2119] In 195 the description of OIDs the convention: Set (S) Get (G) and Trap (T) 196 conventions will describe the action allowed by the parameter. 198 4. Overview 200 Figure 1 shows a set of reference points, for the linear "black link" 201 approach, for single-channel connection (Ss and Rs) between 202 transmitters (Tx) and receivers (Rx). Here the DWDM network elements 203 include an OM and an OD (which are used as a pair with the opposing 204 element), one or more optical amplifiers and may also include one or 205 more OADMs. 207 +-------------------------------------------------+ 208 Ss | DWDM Network Elements | Rs 209 +---+ | | | \ / | | | +--+ 210 Tx L1----|->| \ +------+ +------+ / |--|-->Rx L1 211 +---+ | | | | | +------+ | | | | | +--+ 212 +---+ | | | | | | | | | | | | +--+ 213 Tx L2----|->| OM |-->|------|->| OADM |--|------|->| OD |--|-->Rx L2 214 +---+ | | | | | | | | | | | | +--+ 215 +---+ | | | | | +------+ | | | | | +--+ 216 Tx L3----|->| / | DWDM | | ^ | DWDM | \ |--|-->Rx L3 217 +---+ | | / | Link +----|--|----+ Link | \ | | +--+ 218 +-----------+ | | +----------+ 219 +--+ +--+ 220 | | 221 Rs v | Ss 222 +-----+ +-----+ 223 |RxLx | |TxLx | 224 +-----+ +-----+ 225 Ss = reference point at the DWDM network element tributary output 226 Rs = reference point at the DWDM network element tributary input 227 Lx = Lambda x 228 OM = Optical Mux 229 OD = Optical Demux 230 OADM = Optical Add Drop Mux 232 from Fig. 5.1/G.698.2 234 Figure 1: Linear Black Link approach 236 G.698.2 [ITU.G698.2] defines also Ring "Black Link" approach 237 configurations [Fig. 5.2/G.698.2] and Linear "black link" approach 238 for Bidirectional applications[Fig. 5.3/G.698.2] 240 4.1. Optical Parameters Description 242 The G.698.2 pre-certified network media channels are managed at the 243 edges, i.e. at the transmitters (Tx) and receivers (Rx) attached to 244 the S and R reference points respectively. The set of parameters 245 that could be managed are specified in G.698.2 [ITU.G698.2] section 246 5.3 referring the "application code" notation 248 The definitions of the optical parameters are provided below to 249 increase the readability of the document, where the definition is 250 ended by (G) the parameter can be retrieve with a GET, when (S) it 251 can be provisioned by a SET, (G,S) can be either GET and SET. 253 To support the management of these parameters, the SNMP MIB in RFC 254 3591 [RFC3591] is extended with a new MIB module defined in section 6 255 of this document. This new MIB module includes the definition of new 256 configuration table of the OCh Layer for the parameters at Tx (S) and 257 Rx (R). 259 4.1.1. Rs-Ss Configuration 261 The Rs-Ss configuration table allows configuration of Central 262 Frequency, Power and Application identifiers as described in 263 [ITU.G698.2] and G.694.1 [ITU.G694.1] 264 This parameter report the current Transceiver Output power, it can be 265 either a setting and measured value (G, S). 267 Central frequency (see G.694.1 Table 1): 268 This parameter indicates the central frequency value that Ss and 269 Rs will be set, to work (in THz), in particular Section 6/G.694.1 270 (G, S). 272 Single-channel application identifiers (see G.698.2): 273 This parameter indicates the transceiver application identifier at 274 Ss and Rs as defined in [ITU.G698.2] Chapter 5.4 - this parameter 275 can be called Optical Interface Identifier OII as per [draft- 276 martinelli-wson-interface-class] (G). 278 Number of Single-channel application identifiers Supported 279 This parameter indicates the number of Single-channel application 280 codes supported by this interface (G). 282 Current Laser Output power: 284 This parameter report the current Transceiver Output power, see 285 RFC3591. 287 Current Laser Input power: 288 This parameter report the current Transceiver Input power see 289 RFC3591. 291 +---------------------------------------------+---------+-----------+ 292 | PARAMETERS | Get/Set | Reference | 293 +---------------------------------------------+---------+-----------+ 294 | Central Frequency | G,S | G.694.1 | 295 | | | S.6 | 296 | Single-channel Application Identifier | G | G.874.1 | 297 | number in use | | | 298 | Single-channel Application Identifier Type | G | G.874.1 | 299 | in use | | | 300 | Single-channel Application Identifier in | G | G.874.1 | 301 | use | | | 302 | Number of Single-channel Application | G | N.A. | 303 | Identifiers Supported | | | 304 | Current Output Power | G,S | RFC3591 | 305 | Current Input Power | G | RFC3591 | 306 +---------------------------------------------+---------+-----------+ 308 Table 1: Rs-Ss Configuration 310 4.1.2. Table of Application Identifiers 312 This table has a list of Application Identifiers supported by this 313 interface at point R are defined in G.698.2. 315 Application Identifier Number: 316 The number that uniquely identifies the Application Identifier. 318 Application Identifier Type: 319 Type of application Identifier: STANDARD / PROPRIETARY in G.874.1 321 Note: if the A.I. type = PROPRIETARY, the first 6 Octets of the 322 Application Identifier (PrintableString) must contain the 323 Hexadecimal representation of an OUI (organizationally unique 324 identifier) assigned to the vendor whose implementation generated 325 the Application Identifier; the remaining octets of the 326 PrintableString are unspecified. 328 Application Identifier: 329 This is the application Identifier that is defined in G.874.1. 331 4.2. Use of ifTable 333 This section specifies how the MIB II interfaces group, as defined in 334 RFC 2863 [RFC2863], is used for the link ends of a black link. Only 335 the ifGeneralInformationGroup will be supported for the ifTable and 336 the ifStackTable to maintain the relationship between the OCh and OPS 337 layers. The OCh and OPS layers are managed in the ifTable using 338 IfEntries that correlate to the layers depicted in Figure 1. 340 For example, a device with TX and/or RX will have an Optical Physical 341 Section (OPS) layer, and an OCh layer. There is a one to n 342 relationship between the OPS and OCh layers. 344 EDITOR NOTE: Reason for changing from OChr to OCh: Edition 3 of G.872 345 removed OChr from the architecture and G.709 was subsequently updated 346 to account for this architectural change. 348 Figure 2 In the following figures, opticalPhysicalSection are 349 abbreviated as OPS. 351 _____________________ 352 \ 353 Path Data Unit |\ 354 (ODUk) | \ 355 _____________________| \ __________________ 356 | | | > 357 Tandem Data Unit | | | | 358 (ODUkT) | | OCh Layer | > n och IfEntries 359 _____________________| | | | 360 | |__________________| > 361 Optical | /| | > 362 Transport Unit | / | | | 363 (OTUk) |/ | OPSn Layer | > m ops IfEntries 364 _____________________/ | | | 365 |__________________| > 367 Figure 2: OTN Layers for OPS and OCh 369 Each opticalChannel IfEntry is mapped to one of the m 370 opticalPhysicalSection IfEntries, where m is greater than or equal to 371 1. Conversely, each opticalTransPhysicalSection port entry is mapped 372 to one of the n opticalChannel IfEntries, where n is greater than or 373 equal to 1. 375 The design of the Optical Interface MIB provides the option to model 376 an interface either as a single bidirectional object containing both 377 sink and source functions or as a pair of unidirectional objects, one 378 containing sink functions and the other containing source functions. 380 If the sink and source for a given protocol layer are to be modelled 381 as separate objects, then there need to be two ifTable entries, one 382 that corresponds to the sink and one that corresponds to the source, 383 where the directionality information is provided in the configuration 384 tables for that layer via the associated Directionality objects. The 385 agent is expected to maintain consistent directionality values 386 between ifStackTable layers (e.g., a sink must not be stacked in a 387 1:1 manner on top of a source, or vice-versa), and all protocol 388 layers that are represented by a given ifTable entry are expected to 389 have the same directionality. 391 When separate ifTable entries are used for the source and sink 392 functions of a given physical interface, association between the two 393 uni-directional ifTable entries (one for the source function and the 394 other for the sink functions) should be provided. It is recommended 395 that identical ifName values are used for the two ifTable entries to 396 indicate such association. An implementation shall explicitly state 397 what mechanism is used to indicate the association, if ifName is not 398 used. 400 4.2.1. Use of ifTable for OPS Layer 402 Only the ifGeneralInformationGroup needs to be supported. 404 ifTable Object Use for OTN OPS Layer 405 ===================================================================== 407 ifIndex The interface index. 409 ifDescr Optical Transport Network (OTN) Optical 410 Physical Section (OPS) 412 ifType opticalPhysicalSection (xxx) 414 <<>> 416 ifSpeed Actual bandwidth of the interface in bits per 417 second. If the bandwidth of the interface is 418 greater than the maximum value of 4,294,967,295, 419 then the maximum value is reported and 420 ifHighSpeed must be used to report the 421 interface's speed. 423 ifPhysAddress An octet string with zero length. (There is 424 no specific address associated with the 425 interface.) 427 ifAdminStatus The desired administrative state of the 428 interface. Supports read-only access. 430 ifOperStatus The operational state of the interface. The 431 value lowerLayerDown(7) is not used, since 432 there is no lower layer interface. This object 433 is set to notPresent(6) if a component is 434 missing, otherwise it is set to down(2) if 435 either of the objects optIfOPSnCurrentStatus 436 indicates that any defect is present. 438 ifLastChange The value of sysUpTime at the last change in 439 ifOperStatus. 441 ifName Enterprise-specific convention (e.g., TL-1 AID) 442 to identify the physical or data entity 443 associated with this interface or an 444 OCTET STRING of zero length. The 445 enterprise-specific convention is intended to 446 provide the means to reference one or more 447 enterprise-specific tables. 449 ifLinkUpDownTrapEnable Default value is enabled(1). Supports 450 read-only access. 452 ifHighSpeed Actual bandwidth of the interface in Mega-bits 453 per second. A value of n represents a range of 454 'n-0.5' to 'n+0.499999'. 456 ifConnectorPresent Set to true(1). 458 ifAlias The (non-volatile) alias name for this interface 459 as assigned by the network manager. 461 4.2.2. Use of ifTable for OCh Layer 463 Use of ifTable for OCh Layer See RFC 3591 [RFC3591] section 2.4 465 4.2.3. Use of ifStackTable 467 Use of the ifStackTable and ifInvStackTable to associate the 468 opticalPhysicalSection and opticalChannel interface entries is best 469 illustrated by the example shown in Figure 3. The example assumes an 470 ops interface with ifIndex i that carries two multiplexed OCh 471 interfaces with ifIndex values of j and k, respectively. The example 472 shows that j and k are stacked above (i.e., multiplexed into) i. 473 Furthermore, it shows that there is no layer lower than i and no 474 layer higher than j and/or k. 476 Figure 3 478 HigherLayer LowerLayer 479 -------------------------- 480 0 j 481 0 k 482 j i 483 k i 484 i 0 486 Figure 3: Use of ifStackTable for an OTN port 488 For the inverse stack table, it provides the same information as the 489 interface stack table, with the order of the Higher and Lower layer 490 interfaces reversed. 492 5. Structure of the MIB Module 494 EDITOR NOTE:text will be provided based on the MIB module in 495 Section 6 497 6. Object Definitions 499 EDITOR NOTE: Once the scope in Section 1 and the parameters in 500 Section 4 are finalized, a MIB module will be defined. It could be 501 an extension to the OPT-IF-MIB module of RFC 3591. >>> 502 OPT-IF-698-MIB DEFINITIONS ::= BEGIN 504 IMPORTS 505 MODULE-IDENTITY, 506 OBJECT-TYPE, 507 Gauge32, 508 Integer32, 509 Unsigned32, 510 Counter64, 511 transmission, 512 NOTIFICATION-TYPE 513 FROM SNMPv2-SMI 514 TEXTUAL-CONVENTION, 515 RowPointer, 516 RowStatus, 517 TruthValue, 518 DisplayString, 519 DateAndTime 520 FROM SNMPv2-TC 521 SnmpAdminString 522 FROM SNMP-FRAMEWORK-MIB 523 MODULE-COMPLIANCE, OBJECT-GROUP 524 FROM SNMPv2-CONF 525 ifIndex 526 FROM IF-MIB 527 optIfMibModule 528 FROM OPT-IF-MIB; 530 -- This is the MIB module for the optical parameters - 531 -- Application codes associated with the black link end points. 533 optIfXcvrMibModule MODULE-IDENTITY 534 LAST-UPDATED "201401270000Z" 535 ORGANIZATION "IETF Ops/Camp MIB Working Group" 536 CONTACT-INFO 537 "WG charter: 538 http://www.ietf.org/html.charters/ 540 Mailing Lists: 541 Editor: Gabriele Galimberti 542 Email: ggalimbe@cisco.com" 543 DESCRIPTION 544 "The MIB module to describe Black Link tranceiver 545 characteristics to rfc3591. 547 Copyright (C) The Internet Society (2014). This version 548 of this MIB module is an extension to rfc3591; see the RFC 549 itself for full legal notices." 550 REVISION "201305050000Z" 551 DESCRIPTION 552 "Draft version 1.0" 553 REVISION "201305050000Z" 554 DESCRIPTION 555 "Draft version 2.0" 556 REVISION "201302270000Z" 557 DESCRIPTION 558 "Draft version 3.0" 559 REVISION "201307020000Z" 560 DESCRIPTION 561 "Draft version 4.0 562 Changed the draft to include only the G.698 parameters." 563 REVISION "201311020000Z" 564 DESCRIPTION 565 "Draft version 5.0 566 Mib has a table of application code/vendor 567 transcievercode G.698" 568 REVISION "201401270000Z" 569 DESCRIPTION 570 "Draft version 6.0" 571 REVISION "201407220000Z" 572 DESCRIPTION 573 "Draft version 8.0 574 Removed Vendor transceiver code" 575 REVISION "201502220000Z" 576 DESCRIPTION 577 "Draft version 11.0 578 Added reference to OUI in the first 6 Octets of a proprietary 579 Application code 580 Added a Length field for the Application code 581 Changed some names" 582 ::= { optIfMibModule 4 } 584 ::= { optIfMibModule 4 } 586 -- Addition to the RFC 3591 objects 587 optIfOChSsRsGroup OBJECT IDENTIFIER ::= { optIfXcvrMibModule 1 } 589 -- OCh Ss/Rs config table 590 -- The application code/vendor tranceiver class for the Black Link 591 -- Ss-Rs will be added to the OchConfigTable 593 optIfOChSsRsConfigTable OBJECT-TYPE 594 SYNTAX SEQUENCE OF OptIfOChSsRsConfigEntry 595 MAX-ACCESS not-accessible 596 STATUS current 597 DESCRIPTION 598 "A table of Och General config extension parameters" 599 ::= { optIfOChSsRsGroup 1 } 601 optIfOChSsRsConfigEntry OBJECT-TYPE 602 SYNTAX OptIfOChSsRsConfigEntry 603 MAX-ACCESS not-accessible 604 STATUS current 605 DESCRIPTION 606 "A conceptual row that contains G.698 parameters for an 607 interface." 608 INDEX { ifIndex } 609 ::= { optIfOChSsRsConfigTable 1 } 611 OptIfOChSsRsConfigEntry ::= 612 SEQUENCE { 613 optIfOChCentralFrequency Unsigned32, 614 optIfOChCfgApplicationIdentifierNumber Unsigned32, 615 optIfOChCfgApplicationIdentifierType Unsigned32, 616 optIfOChCfgApplicationIdentifierLength Unsigned32, 617 optIfOChCfgApplicationIdentifier DisplayString, 618 optIfOChNumberApplicationCodesSupported Unsigned32 619 } 621 optIfOChCentralFrequency OBJECT-TYPE 622 SYNTAX Unsigned32 623 MAX-ACCESS read-write 624 UNITS "THz" 625 STATUS current 626 DESCRIPTION 627 " This parameter indicates the frequency of this interface. 628 " 629 ::= { optIfOChSsRsConfigEntry 1 } 631 optIfOChCfgApplicationIdentifierNumber OBJECT-TYPE 632 SYNTAX Unsigned32 633 MAX-ACCESS read-write 634 STATUS current 635 DESCRIPTION 636 "This parameter uniquely indicates the transceiver 637 application code at Ss and Rs as defined in [ITU.G874.1], 638 that is used by this interface. 639 The optIfOChSrcApplicationIdentifierTable has all the 640 application codes supported by this interface. " 641 ::= { optIfOChSsRsConfigEntry 2 } 643 optIfOChCfgApplicationIdentifierType OBJECT-TYPE 644 SYNTAX Unsigned32 645 MAX-ACCESS read-write 646 STATUS current 647 DESCRIPTION 648 "This parameter indicates the transceiver type of 649 application code at Ss and Rs as defined in [ITU.G874.1], 650 that is used by this interface. 651 The optIfOChSrcApplicationIdentifierTable has all the 652 application codes supported by this interface 653 Standard = 0, PROPRIETARY = 1. " 654 ::= { optIfOChSsRsConfigEntry 3 } 656 optIfOChCfgApplicationIdentifierLenght OBJECT-TYPE 657 SYNTAX Unsigned32 658 MAX-ACCESS read-write 659 STATUS current 660 DESCRIPTION 661 "This parameter indicates the number of octets in the 662 Application Identifier. 663 " 664 ::= { optIfOChSsRsConfigEntry 4 } 666 optIfOChCfgApplicationIdentifier OBJECT-TYPE 667 SYNTAX DisplayString 668 MAX-ACCESS read-write 669 STATUS current 670 DESCRIPTION 671 "This parameter indicates the transceiver application code at 672 Ss and Rs as defined in [ITU.G698.2] Chapter 5.3, that 673 is used by this interface. The 674 optIfOChSrcApplicationCodeTable has all the application 675 codes supported by this interface. 676 If the optIfOChCfgApplicationIdentifierType is 1 677 (Proprietary), then the first 6 octets of the printable string 678 will be the OUI (organizationally unique identifier) assigned 679 to the vendor whose implementation generated the Application 680 Identifier." 681 ::= { optIfOChSsRsConfigEntry 5 } 683 optIfOChNumberApplicationIdentifiersSupported OBJECT-TYPE 684 SYNTAX Unsigned32 685 MAX-ACCESS read-only 686 STATUS current 687 DESCRIPTION 688 " Number of Application codes supported by this interface." 689 ::= { optIfOChSsRsConfigEntry 6 } 691 -- Table of Application codes supported by the interface 692 -- OptIfOChSrcApplicationCodeEntry 694 optIfOChSrcApplicationIdentifierTable OBJECT-TYPE 695 SYNTAX SEQUENCE OF OptIfOChSrcApplicationIdentifierEntry 696 MAX-ACCESS not-accessible 697 STATUS current 698 DESCRIPTION 699 "A Table of Application codes supported by this interface." 700 ::= { optIfOChSsRsGroup 2 } 702 optIfOChSrcApplicationIdentifierEntry OBJECT-TYPE 703 SYNTAX OptIfOChSrcApplicationIdentifierEntry 704 MAX-ACCESS not-accessible 705 STATUS current 706 DESCRIPTION 707 "A conceptual row that contains the Application code for this 708 interface." 709 INDEX { ifIndex, optIfOChApplicationIdentiferNumber } 710 ::= { optIfOChSrcApplicationIdentifierTable 1 } 712 OptIfOChSrcApplicationIdentifierEntry ::= 713 SEQUENCE { 714 optIfOChApplicationIdentiferNumber Integer32, 715 optIfOChApplicationIdentiferType Integer32, 716 optIfOChApplicationIdentiferLength Integer32, 717 optIfOChApplicationIdentifier DisplayString 718 } 720 optIfOChApplicationIdentiferNumber OBJECT-TYPE 721 SYNTAX Integer32 (1..255) 722 MAX-ACCESS not-accessible 723 STATUS current 724 DESCRIPTION 725 " The number/identifier of the application code supported at 726 this interface. The interface can support more than one 727 application codes. 728 " 729 ::= { optIfOChSrcApplicationIdentifierEntry 1} 731 optIfOChApplicationIdentiferType OBJECT-TYPE 732 SYNTAX Integer32 (1..255) 733 MAX-ACCESS read-only 734 STATUS current 735 DESCRIPTION 736 " The type of identifier of the application code supported at 737 this interface. The interface can support more than one 738 application codes. 739 Standard = 0, PROPRIETARY = 1 740 " 741 ::= { optIfOChSrcApplicationIdentifierEntry 2} 743 optIfOChApplicationIdentiferLength OBJECT-TYPE 744 SYNTAX Integer32 (1..255) 745 MAX-ACCESS read-only 746 STATUS current 747 DESCRIPTION 748 " This parameter indicates the number of octets in the 749 Application Identifier. 750 " 751 ::= { optIfOChSrcApplicationIdentifierEntry 3} 753 optIfOChApplicationIdentifier OBJECT-TYPE 754 SYNTAX DisplayString 755 MAX-ACCESS read-only 756 STATUS current 757 DESCRIPTION 758 " The application code supported by this interface DWDM 759 link. 760 If the optIfOChApplicationIdentiferType is 1 (Proprietory), 761 then the first 6 octets of the printable string will be the 762 OUI (organizationally unique identifier) assigned to the 763 vendor whose implementation generated the Application 764 Identifier." 765 ::= { optIfOChSrcApplicationIdentifierEntry 4} 767 -- Notifications 769 -- Central Frequency Change Notification 770 optIfOChCentralFrequencyChange NOTIFICATION-TYPE 771 OBJECTS { optIfOChCentralFrequency } 772 STATUS current 773 DESCRIPTION 774 "Notification of a change in the central frequency." 776 ::= { optIfXcvrMibModule 1 } 778 END 780 7. Relationship to Other MIB Modules 782 7.1. Relationship to the [TEMPLATE TODO] MIB 784 7.2. MIB modules required for IMPORTS 786 8. Definitions 788 [TEMPLATE TODO]: put your valid MIB module here. 789 A list of tools that can help automate the process of 790 checking MIB definitions can be found at 791 http://www.ops.ietf.org/mib-review-tools.html 793 9. Security Considerations 795 There are a number of management objects defined in this MIB module 796 with a MAX-ACCESS clause of read-write and/or read-create. Such 797 objects may be considered sensitive or vulnerable in some network 798 environments. The support for SET operations in a non-secure 799 environment without proper protection can have a negative effect on 800 network operations. These are the tables and objects and their 801 sensitivity/vulnerability: 803 o 805 Some of the readable objects in this MIB module (i.e., objects with a 806 MAX-ACCESS other than not-accessible) may be considered sensitive or 807 vulnerable in some network environments. It is thus important to 808 control even GET and/or NOTIFY access to these objects and possibly 809 to even encrypt the values of these objects when sending them over 810 the network via SNMP. 812 SNMP versions prior to SNMPv3 did not include adequate security. 813 Even if the network itself is secure (for example by using IPsec), 814 even then, there is no control as to who on the secure network is 815 allowed to access and GET/SET (read/change/create/delete) the objects 816 in this MIB module. 818 It is RECOMMENDED that implementers consider the security features as 819 provided by the SNMPv3 framework (see [RFC3410], section 8), 820 including full support for the SNMPv3 cryptographic mechanisms (for 821 authentication and privacy). 823 Further, deployment of SNMP versions prior to SNMPv3 is NOT 824 RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to 825 enable cryptographic security. It is then a customer/operator 826 responsibility to ensure that the SNMP entity giving access to an 827 instance of this MIB module is properly configured to give access to 828 the objects only to those principals (users) that have legitimate 829 rights to indeed GET or SET (change/create/delete) them. 831 10. IANA Considerations 833 Option #1: 835 The MIB module in this document uses the following IANA-assigned 836 OBJECT IDENTIFIER values recorded in the SMI Numbers registry: 838 Descriptor OBJECT IDENTIFIER value 839 ---------- ----------------------- 841 sampleMIB { mib-2 XXX } 843 Option #2: 845 Editor's Note (to be removed prior to publication): the IANA is 846 requested to assign a value for "XXX" under the 'mib-2' subtree and 847 to record the assignment in the SMI Numbers registry. When the 848 assignment has been made, the RFC Editor is asked to replace "XXX" 849 (here and in the MIB module) with the assigned value and to remove 850 this note. 852 Note well: prior to official assignment by the IANA, an internet 853 draft MUST use place holders (such as "XXX" above) rather than actual 854 numbers. See RFC4181 Section 4.5 for an example of how this is done 855 in an internet draft MIB module. 857 Option #3: 859 This memo includes no request to IANA. 861 11. Contributors 862 Arnold Mattheus 863 Deutsche Telekom 864 Darmstadt 865 Germany 866 email a.mattheus@telekom.de 868 Manuel Paul 869 Deutsche Telekom 870 Berlin 871 Germany 872 email Manuel.Paul@telekom.de 874 Frank Luennemann 875 Deutsche Telekom 876 Munster 877 Germany 878 email Frank.Luennemann@telekom.de 880 Scott Mansfield 881 Ericsson Inc. 882 email scott.mansfield@ericsson.com 884 Najam Saquib 885 Cisco 886 Ludwig-Erhard-Strasse 3 887 ESCHBORN, HESSEN 65760 888 GERMANY 889 email nasaquib@cisco.com 891 Walid Wakim 892 Cisco 893 9501 Technology Blvd 894 ROSEMONT, ILLINOIS 60018 895 UNITED STATES 896 email wwakim@cisco.com 898 Ori Gerstel 899 Sedona System 900 ISRAEL 901 email orig@sedonasys.com 903 12. References 905 12.1. Normative References 907 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group 908 MIB", RFC 2863, June 2000. 910 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 911 Requirement Levels", BCP 14, RFC 2119, March 1997. 913 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 914 Schoenwaelder, Ed., "Structure of Management Information 915 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 917 [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. 918 Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD 919 58, RFC 2579, April 1999. 921 [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, 922 "Conformance Statements for SMIv2", STD 58, RFC 2580, 923 April 1999. 925 [RFC3591] Lam, H-K., Stewart, M., and A. Huynh, "Definitions of 926 Managed Objects for the Optical Interface Type", RFC 3591, 927 September 2003. 929 [RFC6205] Otani, T. and D. Li, "Generalized Labels for Lambda- 930 Switch-Capable (LSC) Label Switching Routers", RFC 6205, 931 March 2011. 933 [ITU.G698.2] 934 International Telecommunications Union, "Amplified 935 multichannel dense wavelength division multiplexing 936 applications with single channel optical interfaces", 937 ITU-T Recommendation G.698.2, November 2009. 939 [ITU.G709] 940 International Telecommunications Union, "Interface for the 941 Optical Transport Network (OTN)", ITU-T Recommendation 942 G.709, February 2012. 944 [ITU.G872] 945 International Telecommunications Union, "Architecture of 946 optical transport networks", ITU-T Recommendation G.872 947 and Amd.1, October 2012. 949 [ITU.G798] 950 International Telecommunications Union, "Characteristics 951 of optical transport network hierarchy equipment 952 functional blocks", ITU-T Recommendation G.798 and Amd.1, 953 December 2012. 955 [ITU.G874] 956 International Telecommunications Union, "Management 957 aspects of optical transport network elements", ITU-T 958 Recommendation G.874, August 2013. 960 [ITU.G874.1] 961 International Telecommunications Union, "Optical transport 962 network (OTN): Protocol-neutral management information 963 model for the network element view", ITU-T Recommendation 964 G.874.1, October 2012. 966 [ITU.G959.1] 967 International Telecommunications Union, "Optical transport 968 network physical layer interfaces", ITU-T Recommendation 969 G.959.1, November 2009. 971 [ITU.G826] 972 International Telecommunications Union, "End-to-end error 973 performance parameters and objectives for international, 974 constant bit-rate digital paths and connections", ITU-T 975 Recommendation G.826, November 2009. 977 [ITU.G8201] 978 International Telecommunications Union, "Error performance 979 parameters and objectives for multi-operator international 980 paths within the Optical Transport Network (OTN)", ITU-T 981 Recommendation G.8201, April 2011. 983 [ITU.G694.1] 984 International Telecommunications Union, "Spectral grids 985 for WDM applications: DWDM frequency grid", ITU-T 986 Recommendation G.694.1, February 2012. 988 [ITU.G7710] 989 International Telecommunications Union, "Common equipment 990 management function requirements", ITU-T Recommendation 991 G.7710, February 2012. 993 12.2. Informative References 995 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 996 "Introduction and Applicability Statements for Internet- 997 Standard Management Framework", RFC 3410, December 2002. 999 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 1000 June 1999. 1002 [RFC4181] Heard, C., "Guidelines for Authors and Reviewers of MIB 1003 Documents", BCP 111, RFC 4181, September 2005. 1005 [I-D.kunze-g-698-2-management-control-framework] 1006 Kunze, R., "A framework for Management and Control of 1007 optical interfaces supporting G.698.2", draft-kunze- 1008 g-698-2-management-control-framework-00 (work in 1009 progress), July 2011. 1011 [RFC4054] Strand, J. and A. Chiu, "Impairments and Other Constraints 1012 on Optical Layer Routing", RFC 4054, May 2005. 1014 Appendix A. Change Log 1016 This optional section should be removed before the internet draft is 1017 submitted to the IESG for publication as an RFC. 1019 Note to RFC Editor: please remove this appendix before publication as 1020 an RFC. 1022 Appendix B. Open Issues 1024 Note to RFC Editor: please remove this appendix before publication as 1025 an RFC. 1027 Authors' Addresses 1029 Gabriele Galimberti (editor) 1030 Cisco 1031 Via S. Maria Molgora, 48 1032 20871 - Vimercate 1033 Italy 1035 Phone: +390392091462 1036 Email: ggalimbe@cisco.com 1038 Ruediger Kunze (editor) 1039 Deutsche Telekom 1040 Dddd, xx 1041 Berlin 1042 Germany 1044 Phone: +49xxxxxxxxxx 1045 Email: RKunze@telekom.de 1046 Hing-Kam Lam (editor) 1047 Alcatel-Lucent 1048 600-700 Mountain Avenue, Murray Hill 1049 New Jersey, 07974 1050 USA 1052 Phone: +17323313476 1053 Email: kam.lam@alcatel-lucent.com 1055 Dharini Hiremagalur (editor) 1056 Juniper 1057 1194 N Mathilda Avenue 1058 Sunnyvale - 94089 California 1059 USA 1061 Phone: +1408 1062 Email: dharinih@juniper.net 1064 Luyuan Fang (editor) 1065 Microsoft 1066 5600 148th Ave NE 1067 Redmond, WA 98502 1068 USA 1070 Email: lufang@microsoft.com 1072 Gary Ratterree (editor) 1073 Microsoft 1074 5600 148th Ave NE 1075 Redmond, WA 98502 1076 USA 1078 Email: gratt@microsoft.com