idnits 2.17.1 draft-ietf-snanau-appntrapmib-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 10 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 21, 1998) is 9404 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) == Unused Reference: '16' is defined on line 1013, but no explicit reference was found in the text == Unused Reference: '17' is defined on line 1016, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2271 (ref. '1') (Obsoleted by RFC 2571) ** Downref: Normative reference to an Informational RFC: RFC 1215 (ref. '4') ** Obsolete normative reference: RFC 1902 (ref. '5') (Obsoleted by RFC 2578) ** Obsolete normative reference: RFC 1903 (ref. '6') (Obsoleted by RFC 2579) ** Obsolete normative reference: RFC 1904 (ref. '7') (Obsoleted by RFC 2580) ** Downref: Normative reference to an Historic RFC: RFC 1157 (ref. '8') ** Downref: Normative reference to an Historic RFC: RFC 1901 (ref. '9') ** Obsolete normative reference: RFC 1906 (ref. '10') (Obsoleted by RFC 3417) ** Obsolete normative reference: RFC 2272 (ref. '11') (Obsoleted by RFC 2572) ** Obsolete normative reference: RFC 2274 (ref. '12') (Obsoleted by RFC 2574) ** Obsolete normative reference: RFC 1905 (ref. '13') (Obsoleted by RFC 3416) ** Obsolete normative reference: RFC 2273 (ref. '14') (Obsoleted by RFC 2573) ** Obsolete normative reference: RFC 2275 (ref. '15') (Obsoleted by RFC 2575) ** Obsolete normative reference: RFC 2028 (ref. '16') (Obsoleted by RFC 9281) -- Possible downref: Non-RFC (?) normative reference: ref. '18' Summary: 24 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Definitions of Managed Objects 3 for APPN TRAPS 5 July 21, 1998 7 Bob Clouston (editor) 8 Cisco Systems 9 clouston@cisco.com 11 Bob Moore (editor) 12 IBM Corporation 13 remoore@us.ibm.com 15 17 Status of this Memo 19 This document is an Internet Draft. Internet Drafts are working 20 documents of the Internet Engineering Task Force (IETF), its Areas, and 21 its Working Groups. Note that other groups may also distribute working 22 documents as Internet Drafts. 24 Internet Drafts are draft documents valid for a maximum of six months. 25 Internet Drafts may be updated, replaced, or obsoleted by other 26 documents at any time. It is not appropriate to use Internet Drafts as 27 reference material or to cite them other than as a "working draft" or 28 "work in progress." 30 Please check the I-D abstract listing contained in each Internet Draft 31 directory to learn the current status of this or any Internet Draft. 32 Distribution of this document is unlimited. 34 Copyright Notice 36 Copyright (C) The Internet Society (1998). All Rights Reserved. 38 Abstract 40 This memo defines a portion of the Management Information Base (MIB) for 41 use with network management protocols in the Internet community. In 42 particular, it defines objects for receiving notifications from network 43 devices with APPN (Advanced Peer-to-Peer Network) and DLUR (Dependent LU 44 Requester) capabilities. This memo identifies notifications for the 45 APPN and DLUR architecture. 47 This memo does not specify a standard for the Internet community. 49 1. Introduction 51 This document is a product of the SNA NAU Services MIB Working Group. 52 It defines a MIB module for notifications for devices with Advanced 53 Peer-to-Peer Networking (APPN) and Dependent LU Requester (DLUR) 54 capabilities. 56 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 57 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 58 document are to be interpreted as described in RFC 2119 [13]. 60 2. The SNMP Network Management Framework 62 The SNMP Management Framework presently consists of five major 63 components: 65 o An overall architecture, described in RFC 2271 [1]. 67 o Mechanisms for describing and naming objects and events for the 68 purpose of management. The first version of this Structure of 69 Management Information (SMI) is called SMIv1 and described in RFC 70 1155 [2], RFC 1212 [3] and RFC 1215 [4]. The second version, called 71 SMIv2, is described in RFC 1902 [5], RFC 1903 [6] and RFC 1904 [7]. 73 o Message protocols for transferring management information. The 74 first version of the SNMP message protocol is called SNMPv1 and 75 described in RFC 1157 [8]. A second version of the SNMP message 76 protocol, which is not an Internet standards track protocol, is 77 called SNMPv2c and described in RFC 1901 [9] and RFC 1906 [10]. The 78 third version of the message protocol is called SNMPv3 and 79 described in RFC 1906 [10], RFC 2272 [11] and RFC 2274 [12]. 81 o Protocol operations for accessing management information. The first 82 set of protocol operations and associated PDU formats is described 83 in RFC 1157 [8]. A second set of protocol operations and associated 84 PDU formats is described in RFC 1905 [13]. 86 o A set of fundamental applications described in RFC 2273 [14] and 87 the view-based access control mechanism described in RFC 2275 [15]. 89 Managed objects are accessed via a virtual information store, termed the 90 Management Information Base or MIB. Objects in the MIB are defined 91 using the mechanisms defined in the SMI. 93 This memo specifies a MIB module that is compliant to the SMIv2. A MIB 94 conforming to the SMIv1 can be produced through the appropriate 95 translations. The resulting translated MIB must be semantically 96 equivalent, except where objects or events are omitted because no 97 translation is possible (use of Counter64). Some machine readable 98 information in SMIv2 will be converted into textual descriptions in 99 SMIv1 during the translation process. However, this loss of machine 100 readable information is not considered to change the semantics of the 101 MIB. 103 3. Overview 105 This document identifies the set of objects for reporting the status of 106 devices with APPN and DLUR capabilities via notifications. 108 See the SNANAU APPN MIB [18] and SNANAU DLUR MIB [19] for the objects 109 for monitoring the configuration and active characteristics of the 110 devices with APPN and DLUR capabilities. Many objects contained in the 111 notifications of this MIB are imported from the APPN and DLUR MIBs. 112 Implementors of this MIB must also implement the APPN MIB. 113 Implementations that support the appnTrapMibDlurConfGroup and the 114 appnTrapMibDlurNotifGroup must also implement the DLUR MIB. 116 The SNANAU APPN MIB allows a management station to collect the network 117 topology of an APPN network (the network nodes (NNs) in the network and 118 all of transmission groups (TGs) between the network nodes) from an APPN 119 device. It also allows the management station to collect the local 120 topology (TGs to end stations, and locally defined ports and link 121 stations) from an APPN device. While the SNANAU APPN MIB has an 122 efficient way to poll the APPN device for updates to the network 123 topology, using flow reduction sequence numbers (FRSNs) as a table 124 index; it does not have a mechanism to poll the local topology tables 125 (appnLocalTgTable, appnPortTable, and appnLsTable) for status changes. 127 This MIB provides a mechanism for an APPN device to send notifications 128 to inform the management station of status changes to rows of these 129 tables. Status changes include operational state changes, and for TGs 130 also include control-point to control-point (CP-CP) session state 131 changes. A notification is defined for each type of status change for 132 each table. 134 The port and link operational state objects have intermediate states. 135 Notifications are only sent for transition to active or inactive state. 137 Notifications are only sent for row creation if the state is active or 138 operational. This is done to avoid sending a notification as the row is 139 created with an inactive initial state, followed by another notification 140 as the resource is activated. 142 Notifications are only sent for row deletion if the last state was 143 active or operational. In most cases, a resource must be deactivated 144 before it can be deleted, and the deactivation will cause a notification 145 to be sent. There is no need for a second notification to be sent for 146 the row deletion, except for the case where the deletion occurred 147 without deactivation. In this case, the state of the object in the 148 notification will indicate an inactve state, since a deleted resource 149 can no longer be active. 151 The purpose of the appnLocalTgCpCpStateChangeTrap notification is to 152 identify the loss or recovery of CP-CP sessions on a TG while the TG 153 remains operational. Thus this notification is only sent if there is a 154 change to an appnLocalTgCpCpSession object, but not a change to the 155 appnLocalTgOperational object. This notification is never sent for the 156 creation or deletion of a row in the appnLocalTgTable. 158 Each notification always contains an object which is a count of the 159 number of times the status of a row in table has changed since the APPN 160 node was last reinitialized. This enables a management station to 161 detect that it has missed a notification, if it does not get the 162 notifications in numerical sequence. If the notifications are not in 163 sequence, the management station should retrieve the entire table to get 164 the correct status for all rows. 166 Similarly, the SNANAU DLUR MIB provides a mechanism for retrieving the 167 configuration and status of dependent LU server (DLUS) sessions on a 168 device with DLUR capabilities. This MIB defines a notification for a 169 DLUR-DLUS session state change of a row in the dlurDlusTable, in the 170 manner described above. A notification is only sent for a session state 171 transition to active or inactive. As with the above notifications, it 172 is only sent on row creation if the initial state is active; and on row 173 deletion is the last state was active, in which case the notification 174 indicates that the state is now inactive. 176 The SNANAU APPN MIB also provides a mechanism for a management station 177 to collect traffic statistics on intermediate sessions, primarily for 178 accounting purposes. However, when the session is terminated, all 179 statistics from the last poll until the session termination time are 180 lost, since the row for that session is deleted from the appnIsInTable. 181 This MIB defines a notification so that the session's final statistics 182 can be sent to a management station. If the notification is not 183 delivered, the final session statistics are lost. If this is a concern, 184 polling of the appnIsInTable in the APPN MIB should be increased to more 185 likely reduce the time between the last poll and the session 186 termination, thereby reducing the amount of data lost. 188 Highlights of the management functions supported by the APPN TRAP MIB 189 module include the following: 191 o A notification for an APPN local TG operational state change. 193 o A notification for an APPN local TG CP-CP session state change. 195 o A notification for an APPN port operational state change. 197 o A notification for an APPN link station operational state change. 199 o A notification for a DLUR-DLUS session state change. 201 o A notification for reporting final APPN intermediate session 202 statistics. 204 This MIB module does not support: 206 o Objects to query the configuration or status of APPN nodes on 207 demand. 209 o Notifications for changes to local topology tables not related to 210 status. 212 3.1. APPN TRAP MIB Structure 214 The APPN TRAP MIB module contains a group of notifications, and a group 215 of supporting objects. 217 The group of notifications consists of the following notifications: 219 1) appnIsrAccountingDataTrap 220 This notification is generated by an APPN device when an intermediate 221 session is terminating, to report the final accounting statistics of the 222 session. 224 2) appnLocalTgOperStateChangeTrap 226 This notification identifies a change to the appnLocalTgOperational 227 object in a row of the SNANAU APPN MIB appnLocalTgTable. 229 3) appnLocalTgCpCpStateChangeTrap 231 This notification identifies a change to the appnLocalTgCpCpSession 232 object in a row of the SNANAU APPN MIB appnLocalTgTable. 234 4) appnPortOperStateChangeTrap 236 This notification identifies a change to the appnPortOperState object in 237 a row of the SNANAU APPN MIB appnPortTable. 239 5) appnLsOperStateChangeTrap 241 This notification identifies a change to the appnLsOperState object in a 242 row of the SNANAU APPN MIB appnLsTable. 244 6) dlurDlusStateChangeTrap 246 This notification identifies a change to the dlurDlusSessnStatus object 247 in a row of the SNANAU DLUR MIB dlurDlusTable. 249 The group of supporting objects contains the appnTrapControl object, 250 which controls whether the APPN device generates each type of 251 notification. Note that generation of the appnIsrAccountingDataTrap is 252 not controlled by this object; instead it is controlled by the 253 appnIsInGlobalCtrAdminStatus object in the SNANAU APPN MIB. 255 Although APPN notification generation could be controlled solely by 256 entries in the snmpNotificationMIB, RFC 2273 [9], the appnTrapControl 257 object exists in this MIB so that implementations are not required to 258 implement RFC 2273 to control generation of APPN notifications. For a 259 notification to be generated and sent as a TRAP or INFORM, the 260 notification type must first be enabled by the appnTrapControl object. 261 It must also not be disabled by an snmpNotificationMIB entry. The 262 destination of notifications is not within the scope of this MIB. 264 Also contained in this group are objects for the TG, port, link, and 265 DLUR-DLUS session notifications to indicate the number of times each of 266 the tables has had a status change of a row since the APPN node was last 267 reinitialized. 269 4. Definitions 271 APPN-TRAP-MIB DEFINITIONS ::= BEGIN 273 IMPORTS 275 Counter32, OBJECT-TYPE, MODULE-IDENTITY, 276 NOTIFICATION-TYPE 277 FROM SNMPv2-SMI 279 TEXTUAL-CONVENTION 280 FROM SNMPv2-TC 282 MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP 283 FROM SNMPv2-CONF 285 appnMIB, appnIsInP2SFmdPius, appnIsInS2PFmdPius, 286 appnIsInP2SNonFmdPius, appnIsInS2PNonFmdPius, 287 appnIsInP2SFmdBytes, appnIsInS2PFmdBytes, 288 appnIsInP2SNonFmdBytes, appnIsInS2PNonFmdBytes, 289 appnIsInSessUpTime, appnObjects, 290 appnLocalTgDestVirtual, appnLocalTgDlcData, 291 appnLocalTgPortName, appnLocalTgQuiescing, 292 appnLocalTgOperational, appnLocalTgCpCpSession, 293 appnLocalTgEffCap, appnLocalTgConnCost, 294 appnLocalTgByteCost, appnLocalTgSecurity, 295 appnLocalTgDelay, appnLocalTgUsr1, 296 appnLocalTgUsr2, appnLocalTgUsr3, 297 appnLocalTgHprSup, appnLocalTgIntersubnet, 298 appnLocalTgMltgLinkType, appnLocalTgBranchLinkType, 299 appnPortOperState, appnPortDlcType, 300 appnPortPortType, appnPortSIMRIM, 301 appnPortLsRole, appnPortNegotLs, 302 appnPortDynamicLinkSupport, appnPortMaxRcvBtuSize, 303 appnPortMaxIframeWindow, appnPortSpecific, 304 appnPortDlcLocalAddr, appnPortCounterDisconTime, 305 appnLsOperState, appnLsPortName, 306 appnLsDlcType, appnLsDynamic, 307 appnLsAdjCpName, appnLsAdjNodeType, 308 appnLsTgNum, appnLsLimResource, 309 appnLsActOnDemand, appnLsMigration, 310 appnLsPartnerNodeId, appnLsCpCpSessionSupport, 311 appnLsMaxSendBtuSize, appnLsSpecific, 312 appnLsHprSup, appnLsErrRecoSup, 313 appnLsForAnrLabel, appnLsRevAnrLabel, 314 appnLsCpCpNceId, appnLsRouteNceId, 315 appnLsBfNceId, appnLsLocalAddr, 317 appnLsRemoteAddr, appnLsRemoteLsName, 318 appnLsCounterDisconTime, appnCompliances, appnGroups 319 FROM APPN-MIB 321 dlurDlusSessnStatus 322 FROM APPN-DLUR-MIB; 324 appnTrapMIB MODULE-IDENTITY 325 LAST-UPDATED "9807160000Z" -- July 16, 1998 326 ORGANIZATION "IETF SNA NAU MIB WG / AIW APPN MIBs SIG" 327 CONTACT-INFO 329 " 330 Bob Clouston 331 Cisco Systems 332 7025 Kit Creek Road 333 P.O. Box 14987 334 Research Triangle Park, NC 27709, USA 335 Tel: 1 919 472 2333 336 E-mail: clouston@cisco.com 338 Bob Moore 339 IBM Corporation 340 4205 S. Miami Boulevard 341 BRQA/501 342 P.O. Box 12195 343 Research Triangle Park, NC 27709, USA 344 Tel: 1 919 254 4436 345 E-mail: remoore@us.ibm.com 346 " 347 DESCRIPTION 348 "This MIB module defines notifications to be generated by 349 network devices with APPN capabilities. It presupposes 350 support for the APPN MIB (RFC 2155). It also presupposes 351 support for the DLUR MIB (RFC 2232) for implementations 352 that support the DLUR-related groups." 354 ::= { appnMIB 0 } 356 -- ********************************************************************* 357 -- Textual Conventions 358 -- ********************************************************************* 359 AppnLastChangeType ::= TEXTUAL-CONVENTION 360 STATUS current 361 DESCRIPTION 362 "A value reporting the type of the last change made to 363 a specified table. Defined values are: 365 addition(1) - a new row was added to the table 366 deletion(2) - an existing row was removed from 367 the table 368 modification(3) - the value of one or more objects 369 in an existing row of the table 370 changed. Changes to objects with 371 the syntax counter32 or counter64 372 are not considered modifications. 373 Changes to other objects may also 374 be excluded in the definition of 375 an object having this syntax." 377 SYNTAX INTEGER { addition(1), 378 deletion(2), 379 modification(3) 380 } 381 -- ********************************************************************* 382 -- Notifications 383 -- ********************************************************************* 385 appnIsrAccountingDataTrap NOTIFICATION-TYPE 386 OBJECTS { 387 appnIsInP2SFmdPius, 388 appnIsInS2PFmdPius, 389 appnIsInP2SNonFmdPius, 390 appnIsInS2PNonFmdPius, 391 appnIsInP2SFmdBytes, 392 appnIsInS2PFmdBytes, 393 appnIsInP2SNonFmdBytes, 394 appnIsInS2PNonFmdBytes, 395 appnIsInSessUpTime 396 } 397 STATUS current 398 DESCRIPTION 399 "When it has been enabled, this notification is generated by an 400 APPN node whenever an ISR session passing through the node is 401 taken down, regardless of whether the session went down 402 normally or abnormally. Its purpose is to allow a management 403 application (primarily an accounting application) that is 404 monitoring the ISR counts to receive the final values of these 405 counts, so that the application can properly account for the 406 amounts the counts were incremented since the last time the 407 application polled them. The appnIsInSessUpTime object 408 provides the total amount of time that the session was active. 410 This notification is not a substitute for polling the ISR 411 counts. In particular, the count values reported in this 412 notification cannot be assumed to be the complete totals for 413 the life of the session, since they may have wrapped while the 414 session was up. 416 The session to which the objects in this notification apply is 417 identified by the fully qualified CP name and PCID that make up 418 the table index. An instance of this notification will contain 419 exactly one instance of each of its objects, and these objects 420 will all belong to the same conceptual row of the 421 appnIsInTable. 423 Generation of this notification is controlled by the same 424 object in the APPN MIB, appnIsInGlobeCtrAdminStatus, that 425 controls whether the count objects themselves are being 426 incremented." 428 ::= { appnTrapMIB 1 } 430 appnLocalTgTopoChangeTrap NOTIFICATION-TYPE 431 OBJECTS { 432 appnLocalTgTableChanges, 433 appnLocalTgTableLastChangeType, 434 appnLocalTgDestVirtual, 435 appnLocalTgDlcData, 436 appnLocalTgPortName, 437 appnLocalTgQuiescing, 438 appnLocalTgOperational, 439 appnLocalTgCpCpSession, 440 appnLocalTgEffCap, 441 appnLocalTgConnCost, 442 appnLocalTgByteCost, 443 appnLocalTgSecurity, 444 appnLocalTgDelay, 445 appnLocalTgUsr1, 446 appnLocalTgUsr2, 447 appnLocalTgUsr3, 448 appnLocalTgHprSup, 449 appnLocalTgIntersubnet, 450 appnLocalTgMltgLinkType, 451 appnLocalTgBranchLinkType 452 } 453 STATUS current 454 DESCRIPTION 455 "When it has been enabled, this notification makes it possible 456 for an APPN topology application to get asynchronous 457 notifications of local topology changes, and thus to reduce the 458 frequency with which it polls for these changes. The 459 notification is more than a simple 'poll me now' indication. 460 It carries both a count of local TG topology changes, and the 461 updated objects themselves. The count of changes allows an 462 application to detect lost notifications, either when polling 463 or upon receiving a subsequent notification, at which point it 464 knows it must retrieve the entire appnLocalTgTable again. 466 An instance of this notification reports a change (addition, 467 deletion, or modification) to a single row in the 468 appnLocalTgTable. It contains the two global objects 469 appnLocalTgTableChanges and appnLocalTgTableLastChangeType, 470 plus one or more objects from the affected row, as follows: 472 - For an addition to the table, all the objects in the 473 new row; 474 - For a deletion, the appnLocalTgDestVirtual object; 475 - For a modification, all the objects whose values 476 changed. 478 The choice of appnLocalTgDestVirtual as the object to include 479 in the deletion case was totally arbitrary. All the receiving 480 application needs is some object from the deleted row, so it 481 can determine the index of the row. 483 Generation of this notification is controlled by the 484 appnTrapControl object." 486 ::= { appnTrapMIB 2 } 488 appnPortChangeTrap NOTIFICATION-TYPE 489 OBJECTS { 490 appnPortTableChanges, 491 appnPortTableLastChangeType, 492 appnPortOperState, 493 appnPortDlcType, 494 appnPortPortType, 495 appnPortSIMRIM, 496 appnPortLsRole, 497 appnPortNegotLs, 498 appnPortDynamicLinkSupport, 499 appnPortMaxRcvBtuSize, 500 appnPortMaxIframeWindow, 501 appnPortSpecific, 502 appnPortDlcLocalAddr, 503 appnPortCounterDisconTime 504 } 505 STATUS current 506 DESCRIPTION 507 "When it has been enabled, this notification makes it possible 508 for an APPN topology application to get asynchronous 509 notifications of port table changes, and thus to reduce the 510 frequency with which it polls for these changes. The 511 notification is more than a simple 'poll me now' indication. 512 It carries both a count of port table changes, and the updated 513 objects themselves. The count of changes allows an application 514 to detect lost notifications, either when polling or upon 515 receiving a subsequent notification, at which point it knows it 516 must retrieve the entire appnPortTable again. 518 An instance of this notification reports a change (addition, 519 deletion, or modification) to a single row in the 520 appnPortTable. It contains the two global objects 521 appnPortTableChanges and appnPortTableLastChangeType, plus one 522 or more objects from the affected row, as follows: 524 - For an addition to the table, all the objects listed 525 here in the new row; 526 - For a deletion, only the appnPortDlcType object; 527 - For a modification, all the objects listed here 528 whose values changed. 530 Note that the counter objects in the appnPortTable are not 531 included here, since notifications should not be issued as they 532 are incremented. 534 The choice of appnPortDlcType as the object to include in the 535 deletion case was totally arbitrary. All the receiving 536 application needs is some object from the deleted row, so it 537 can determine the index of the row. 539 Generation of this notification is controlled by the 540 appnTrapControl object." 542 ::= { appnTrapMIB 3 } 544 appnLsChangeTrap NOTIFICATION-TYPE 545 OBJECTS { 546 appnLsTableChanges, 547 appnLsTableLastChangeType, 548 appnLsOperState, 549 appnLsPortName, 550 appnLsDlcType, 551 appnLsDynamic, 552 appnLsAdjCpName, 553 appnLsAdjNodeType, 554 appnLsTgNum, 555 appnLsLimResource, 556 appnLsActOnDemand, 557 appnLsMigration, 558 appnLsPartnerNodeId, 559 appnLsCpCpSessionSupport, 560 appnLsMaxSendBtuSize, 561 appnLsSpecific, 562 appnLsHprSup, 563 appnLsErrRecoSup, 564 appnLsForAnrLabel, 565 appnLsRevAnrLabel, 566 appnLsCpCpNceId, 567 appnLsRouteNceId, 568 appnLsBfNceId, 569 appnLsLocalAddr, 570 appnLsRemoteAddr, 571 appnLsRemoteLsName, 572 appnLsCounterDisconTime 573 } 574 STATUS current 575 DESCRIPTION 576 "When it has been enabled, this notification makes it possible 577 for an APPN topology application to get asynchronous 578 notifications of link station table changes, and thus to reduce 579 the frequency with which it polls for these changes. The 580 notification is more than a simple 'poll me now' indication. 581 It carries both a count of link station table changes, and the 582 updated objects themselves. The count of changes allows an 583 application to detect lost notifications, either when polling 584 or upon receiving a subsequent notification, at which point it 585 knows it must retrieve the entire appnLsTable again. 587 An instance of this notification reports a change (addition, 588 deletion, or modification) to a single row in the appnLsTable. 589 It contains the two global objects appnLsTableChanges and 590 appnLsTableLastChangeType, plus one or more objects from the 591 affected row, as follows: 593 - For an addition to the table, all the objects 594 listed here in the new row; 595 - For a deletion, only the appnLsPortName object; 596 - For a modification, all the objects listed here 597 whose values changed. 599 Note that the counter and gauge objects in the appnLsTable are 600 not included here, since notifications should not be issued as 601 their values change. 603 The choice of appnLsPortName as the object to include in the 604 deletion case was totally arbitrary. All the receiving 605 application needs is some object from the deleted row, so it 606 can determine the index of the row. 608 Generation of this notification is controlled by the 609 appnTrapControl object." 611 ::= { appnTrapMIB 4 } 613 dlurDlusChangeTrap NOTIFICATION-TYPE 614 OBJECTS { 615 dlurDlusTableChanges, 616 dlurDlusTableLastChangeType, 617 dlurDlusSessnStatus 618 } 619 STATUS current 620 DESCRIPTION 621 "When it has been enabled, this notification makes it possible 622 for an APPN topology application to get asynchronous 623 notifications of DLUR-DLUS table changes, and thus to reduce 624 the frequency with which it polls for these changes. The 625 notification is more than a simple 'poll me now' indication. 626 It carries both a count of DLUR-DLUS table changes, and the 627 updated objects themselves. The count of changes allows an 628 application to detect lost notifications, either when polling 629 or upon receiving a subsequent notification, at which point it 630 knows it must retrieve the entire dlurDlusTable again. 632 An instance of this notification reports a change (addition, 633 deletion, or modification) to a single row in the 634 dlurDlusTable. It contains the two global objects 635 dlurDlusTableChanges and dlurDlusTableLastChangeType, plus 636 the table's one accessible object: dlurDlusSessnStatus. 638 Generation of this notification is controlled by the 639 appnTrapControl object." 641 ::= { appnTrapMIB 5 } 643 -- ********************************************************************* 644 -- Supporting Objects 645 -- ********************************************************************* 647 appnTrapObjects OBJECT IDENTIFIER ::= { appnObjects 7 } 649 appnTrapControl OBJECT-TYPE 651 SYNTAX BITS { 652 appnLocalTgTopoChangeTrap(0), 653 appnPortChangeTrap(1), 654 appnLsChangeTrap(2), 655 dlurDlusChangeTrap(3) 656 -- add other notification types here 657 } 658 MAX-ACCESS read-write 659 STATUS current 660 DESCRIPTION 661 "An object to turn APPN notification generation on and off. 662 Setting a notification type's bit to 1 enables generation of 663 notifications of that type, subject to further filtering 664 resulting from entries in the snmpNotificationMIB. Setting 665 this bit to 0 disables generation of notifications of that 666 type. 668 Note that generation of the appnIsrAccountingDataTrap is 669 controlled by the appnIsInGlobeCtrAdminStatus object in 670 the APPN MIB: if counts of intermediate session traffic 671 are being kept at all, then the notification is also enabled." 673 ::= { appnTrapObjects 1 } 675 appnLocalTgTableChanges OBJECT-TYPE 676 SYNTAX Counter32 677 MAX-ACCESS read-only 678 STATUS current 679 DESCRIPTION 680 "A count of the number of times the appnLocalTgTable has 681 changed since the APPN node was last reinitialized. 682 Addition, deletion, or modification of a row in the table 683 counts as a single change." 685 ::= { appnTrapObjects 2 } 687 appnLocalTgTableLastChangeType OBJECT-TYPE 688 SYNTAX AppnLastChangeType 689 MAX-ACCESS read-only 690 STATUS current 691 DESCRIPTION 692 "An object reporting the type of the last change made 693 to the appnLocalTgTable." 695 ::= { appnTrapObjects 3 } 697 appnPortTableChanges OBJECT-TYPE 698 SYNTAX Counter32 699 MAX-ACCESS read-only 700 STATUS current 701 DESCRIPTION 702 "A count of the number of times the appnPortTable has 703 changed since the APPN node was last reinitialized. 704 Addition, deletion, or modification of a row in the table 705 counts as a single change." 707 ::= { appnTrapObjects 4 } 709 appnPortTableLastChangeType OBJECT-TYPE 710 SYNTAX AppnLastChangeType 711 MAX-ACCESS read-only 712 STATUS current 713 DESCRIPTION 714 "An object reporting the type of the last change made 715 to the appnPortTable." 717 ::= { appnTrapObjects 5 } 719 appnLsTableChanges OBJECT-TYPE 720 SYNTAX Counter32 721 MAX-ACCESS read-only 722 STATUS current 723 DESCRIPTION 724 "A count of the number of times the appnLsTable has 725 changed since the APPN node was last reinitialized. 726 Addition, deletion, or modification of a row in the table 727 counts as a single change." 729 ::= { appnTrapObjects 6 } 731 appnLsTableLastChangeType OBJECT-TYPE 732 SYNTAX AppnLastChangeType 733 MAX-ACCESS read-only 734 STATUS current 735 DESCRIPTION 736 "An object reporting the type of the last change made 737 to the appnLsTable." 739 ::= { appnTrapObjects 7 } 741 dlurDlusTableChanges OBJECT-TYPE 742 SYNTAX Counter32 743 MAX-ACCESS read-only 744 STATUS current 745 DESCRIPTION 746 "A count of the number of times the dlurDlusTable has 747 changed since the APPN node was last reinitialized. 748 Addition, deletion, or modification of a row in the table 749 counts as a single change." 751 ::= { appnTrapObjects 8 } 753 dlurDlusTableLastChangeType OBJECT-TYPE 754 SYNTAX AppnLastChangeType 755 MAX-ACCESS read-only 756 STATUS current 757 DESCRIPTION 759 "An object reporting the type of the last change made 760 to the dlurDlusTable." 762 ::= { appnTrapObjects 9 } 764 -- ********************************************************************* 765 -- Conformance information 766 -- ********************************************************************* 768 -- Tie into the conformance structure in the APPN MIB: 769 -- appnConformance OBJECT IDENTIFIER ::= {appnMIB 3 } 770 -- 771 -- appnCompliances OBJECT IDENTIFIER ::= {appnConformance 1 } 772 -- appnGroups OBJECT IDENTIFIER ::= {appnConformance 2 } 774 -- Compliance statement 775 appnTrapMibCompliance MODULE-COMPLIANCE 776 STATUS current 777 DESCRIPTION 778 "The compliance statement for the SNMP entities that 779 implement the APPN-TRAP-MIB." 781 MODULE -- this module 783 -- Conditionally mandatory groups 784 GROUP appnTrapMibIsrNotifGroup 785 DESCRIPTION 786 "This group is mandatory for APPN nodes supporting 787 reporting of final ISR counter values via notifications." 789 GROUP appnTrapMibTopoConfGroup 790 DESCRIPTION 791 "This group is mandatory for APPN nodes supporting 792 polling reduction for local topology." 794 GROUP appnTrapMibTopoNotifGroup 795 DESCRIPTION 796 "This group is mandatory for APPN nodes supporting 797 polling reduction for local topology." 799 GROUP appnTrapMibDlurConfGroup 800 DESCRIPTION 801 "This group is mandatory for APPN nodes supporting 802 polling reduction for the dlurDlusTable." 804 GROUP appnTrapMibDlurNotifGroup 805 DESCRIPTION 806 "This group is mandatory for APPN nodes supporting 807 polling reduction for the dlurDlusTable." 809 OBJECT appnTrapControl 810 MIN-ACCESS read-only 811 DESCRIPTION 812 "An agent is not required to support a set to 813 this object." 815 ::= {appnCompliances 2 } 817 -- Units of conformance 818 appnTrapMibIsrNotifGroup NOTIFICATION-GROUP 819 NOTIFICATIONS { 820 appnIsrAccountingDataTrap 821 } 822 STATUS current 823 DESCRIPTION 824 "A notification for reporting the final values of the 825 APPN MIB's ISR counters." 827 ::= { appnGroups 21 } 829 appnTrapMibTopoConfGroup OBJECT-GROUP 830 OBJECTS { 831 appnTrapControl, 832 appnLocalTgTableChanges, 833 appnLocalTgTableLastChangeType, 834 appnPortTableChanges, 835 appnPortTableLastChangeType, 836 appnLsTableChanges, 837 appnLsTableLastChangeType 838 } 839 STATUS current 840 DESCRIPTION 841 "A collection of objects for reducing the polling 842 associated with the local topology tables in the 843 APPN MIB. Nodes that implement this group SHALL 844 also implement the appnTrapMibTopoNotifGroup." 846 ::= { appnGroups 22 } 848 appnTrapMibTopoNotifGroup NOTIFICATION-GROUP 849 NOTIFICATIONS { 850 appnLocalTgTopoChangeTrap, 851 appnPortChangeTrap, 852 appnLsChangeTrap 853 } 854 STATUS current 855 DESCRIPTION 856 "A collection of notifications for reducing the polling 857 associated with the local topology tables in the 858 APPN MIB. Nodes that implement this group SHALL 859 also implement the appnTrapMibTopoConfGroup." 861 ::= { appnGroups 23 } 863 appnTrapMibDlurConfGroup OBJECT-GROUP 864 OBJECTS { 865 appnTrapControl, 866 dlurDlusTableChanges, 867 dlurDlusTableLastChangeType 868 } 869 STATUS current 870 DESCRIPTION 871 "A collection of objects for reducing the polling 872 associated with the dlurDlusTable in the DLUR 873 MIB. Nodes that implement this group SHALL also 874 implement the appnTrapMibDlurNotifGroup." 876 ::= { appnGroups 24 } 878 appnTrapMibDlurNotifGroup NOTIFICATION-GROUP 879 NOTIFICATIONS { 880 dlurDlusChangeTrap 881 } 882 STATUS current 883 DESCRIPTION 884 "A notification for reducing the polling associated 885 with the dlurDlusTable in the DLUR MIB. Nodes that 886 implement this group SHALL also implement the 887 appnTrapMibDlurConfGroup." 889 ::= { appnGroups 25 } 891 END 892 5. Security Considerations 894 Certain management information defined in this MIB may be considered 895 sensitive in some network environments. Therefore, authentication of 896 received SNMP requests and controlled access to management information 897 SHOULD be employed in such environments. An authentication protocol is 898 defined in [12]. A protocol for access control is defined in [15]. 900 None of the read-only objects in the APPN TRAP MIB reports a password, 901 user data, or anything else that is particularly sensitive. Some 902 enterprises view their network configuration itself, as well as 903 information about network usage and performance, as corporate assets; 904 such enterprises may wish to restrict SNMP access to most of the objects 905 in the MIB. 907 There is one read-write object in the APPN TRAP MIB, appnTrapControl. 908 This object controls the generation of the notifications defined in the 909 APPN TRAP MIB. 911 6. Intellectual Property 913 The IETF takes no position regarding the validity or scope of any 914 intellectual property or other rights that might be claimed to pertain 915 to the implementation or use of the technology described in this 916 document or the extent to which any license under such rights might or 917 might not be available; neither does it represent that it has made any 918 effort to identify any such rights. Information on the IETF's 919 procedures with respect to rights in standards-track and standards- 920 related documentation can be found in BCP-11 [16]. Copies of claims of 921 rights made available for publication and any assurances of licenses to 922 be made available, or the result of an attempt made to obtain a general 923 license or permission for the use of such proprietary rights by 924 implementers or users of this specification can be obtained from the 925 IETF Secretariat. 927 The IETF invites any interested party to bring to its attention any 928 copyrights, patents or patent applications, or other proprietary rights 929 which may cover technology that may be required to practice this 930 standard. Please address the information to the IETF Executive 931 Director. 933 7. Acknowledgments 935 This MIB module is the product of the IETF SNA NAU MIB WG and the AIW 936 APPN/HPR MIBs SIG. 938 8. References 940 [1] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for 941 Describing SNMP Management Frameworks", RFC 2271, Cabletron 942 Systems, Inc., BMC Software, Inc., IBM T. J. Watson Research, 943 January 1998 945 [2] Rose, M., and K. McCloghrie, "Structure and Identification of 946 Management Information for TCP/IP-based Internets", RFC 1155, 947 Performance Systems International, Hughes LAN Systems, May 1990 949 [3] Rose, M., and K. McCloghrie, "Concise MIB Definitions", RFC 1212, 950 Performance Systems International, Hughes LAN Systems, March 1991 952 [4] M. Rose, "A Convention for Defining Traps for use with the SNMP", 953 RFC 1215, Performance Systems International, March 1991 955 [5] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure 956 of Management Information for Version 2 of the Simple Network 957 Management Protocol (SNMPv2)", RFC 1902, SNMP Research,Inc., Cisco 958 Systems, Inc., Dover Beach Consulting, Inc., International Network 959 Services, January 1996. 961 [6] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Textual 962 Conventions for Version 2 of the Simple Network Management Protocol 963 (SNMPv2)", RFC 1903, SNMP Research, Inc., Cisco Systems, Inc., 964 Dover Beach Consulting, Inc., International Network Services, 965 January 1996. 967 [7] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Conformance 968 Statements for Version 2 of the Simple Network Management Protocol 969 (SNMPv2)", RFC 1904, SNMP Research, Inc., Cisco Systems, Inc., 970 Dover Beach Consulting, Inc., International Network Services, 971 January 1996. 973 [8] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network 974 Management Protocol", RFC 1157, SNMP Research, Performance Systems 975 International, Performance Systems International, MIT Laboratory 976 for Computer Science, May 1990. 978 [9] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, 979 "Introduction to Community-based SNMPv2", RFC 1901, SNMP Research, 980 Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., 981 International Network Services, January 1996. 983 [10] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Transport 984 Mappings for Version 2 of the Simple Network Management Protocol 985 (SNMPv2)", RFC 1906, SNMP Research, Inc., Cisco Systems, Inc., 986 Dover Beach Consulting, Inc., International Network Services, 987 January 1996. 989 [11] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message 990 Processing and Dispatching for the Simple Network Management 991 Protocol (SNMP)", RFC 2272, SNMP Research, Inc., Cabletron Systems, 992 Inc., BMC Software, Inc., IBM T. J. Watson Research, January 1998. 994 [12] Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) for 995 version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 996 2274, IBM T. J. Watson Research, January 1998. 998 [13] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol 999 Operations for Version 2 of the Simple Network Management Protocol 1000 (SNMPv2)", RFC 1905, SNMP Research, Inc., Cisco Systems, Inc., 1001 Dover Beach Consulting, Inc., International Network Services, 1002 January 1996. 1004 [14] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", RFC 1005 2273, SNMP Research, Inc., Secure Computing Corporation, Cisco 1006 Systems, January 1998 1008 [15] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access 1009 Control Model (VACM) for the Simple Network Management Protocol 1010 (SNMP)", RFC 2275, IBM T. J. Watson Research, BMC Software, Inc., 1011 Cisco Systems, Inc., January 1998 1013 [16] Hovey, R., and S. Bradner, "The Organizations Involved in the IETF 1014 Standards Process", BCP 11, RFC 2028, October 1996. 1016 [17] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1017 Levels", BCP 14, RFC 2119, March 1997. 1019 [18] Clouston, B., and B. Moore, "Definition of Managed Objects for APPN 1020 using SMIv2", July 1998. 1022 [19] Clouston, B., and B. Moore, "Definitions of Managed Objects for 1023 DLUR", RFC 2232, November 1997. 1025 9. Authors' Addresses 1027 Bob Clouston 1028 Cisco Systems 1029 7025 Kit Creek Road 1030 P.O. Box 14987 1031 Research Triangle Park, NC 27709, USA 1033 Tel: 1 919 472 2333 1034 E-mail: clouston@cisco.com 1036 Robert Moore 1037 Dept. BRQA/Bldg. 501/G114 1038 IBM Corporation 1039 P.O.Box 12195 1040 3039 Cornwallis 1041 Research Triangle Park, NC 27709, USA 1043 Tel: 1 919 254 4436 1044 E-mail: remoore@us.ibm.com 1046 10. Full Copyright Statement 1048 Copyright (C) The Internet Society (1998). All Rights Reserved. 1050 This document and translations of it may be copied and furnished to 1051 others, and derivative works that comment on or otherwise explain it or 1052 assist in its implementation may be prepared, copied, published and 1053 distributed, in whole or in part, without restriction of any kind, 1054 provided that the above copyright notice and this paragraph are included 1055 on all such copies and derivative works. However, this document itself 1056 may not be modified in any way, such as by removing the copyright notice 1057 or references to the Internet Society or other Internet organizations, 1058 except as needed for the purpose of developing Internet standards in 1059 which case the procedures for copyrights defined in the Internet 1060 Standards process must be followed, or as required to translate it into 1061 languages other than English. 1063 The limited permissions granted above are perpetual and will not be 1064 revoked by the Internet Society or its successors or assigns. 1066 This document and the information contained herein is provided on an "AS 1067 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 1068 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 1069 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 1070 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 1071 FITNESS FOR A PARTICULAR PURPOSE. 1073 Table of Contents 1075 1. Introduction ........................................... 2 1076 2. The SNMP Network Management Framework .................. 2 1077 3. Overview ............................................... 3 1078 3.1 APPN TRAP MIB structure .............................. 5 1079 4. Definitions ............................................ 8 1080 5. Security Considerations ................................ 22 1081 6. Intellectual Property .................................. 22 1082 7. Acknowledgments ........................................ 22 1083 8. References ............................................. 23 1084 9. Author's Addresses ..................................... 24 1085 10. Full Copyright Statement ............................... 25