idnits 2.17.1 draft-ietf-ifmib-testmib-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-03-28) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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 == The page length should not exceed 58 lines per page, but there was 25 longer pages, the longest (page 2) being 116 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** 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 abstract seems to contain references ([6]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (November 25, 1996) is 9985 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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 section? '6' on line 961 looks like a reference -- Missing reference section? '1' on line 932 looks like a reference -- Missing reference section? '2' on line 938 looks like a reference -- Missing reference section? '3' on line 943 looks like a reference -- Missing reference section? '4' on line 948 looks like a reference -- Missing reference section? '5' on line 954 looks like a reference -- Missing reference section? '7' on line 965 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 2 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Definitions of Managed Objects for 3 System and Interface Testing 5 November 25, 1996 7 9 Maria Greene 10 Ascom Nexion 11 greene@nexen.com 13 Keith McCloghrie 14 Cisco Systems 15 kzm@cisco.com 17 Kaj Tesink 18 Bell Communications Research 19 kaj@cc.bellcore.com 21 Status of this Memo 23 This document is an Internet-Draft. Internet-Drafts are working 24 documents of the Internet Engineering Task Force (IETF), its Areas, 25 and its Working Groups. Note that other groups may also distribute 26 working documents as Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as a "work in progress". 33 To learn the current status of any Internet-Draft, please check the 34 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 35 Directories on ds.internic.net (US East Coast), nic.nordu.net 36 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 37 Rim). 39 Abstract 41 This memo defines an experimental portion of the Management 42 Information Base (MIB) for use with network management protocols in 43 the Internet community. In particular, it describes objects used for 44 testing systems and interfaces. This memo replaces the objects 45 originally defined in the ifTestGroup of RFC1573, the IF-MIB [6], 46 which have been deprecated. 48 This memo specifies a MIB module in a manner that is both compliant 49 to the SNMPv2 SMI, and semantically identical to the peer SNMPv1 50 definitions. 52 This memo does not specify a standard for the Internet community. 54 1. The SNMP Network Management Framework 56 The SNMP Network Management Framework presently consists of three 57 major components. They are: 59 o the SMI, described in RFC 1902 [1] - the mechanisms used for 60 describing and naming objects for the purpose of management. 62 o the MIB-II, STD 17, RFC 1213 [2] - the core set of managed 63 objects for the Internet suite of protocols. 65 o the protocol, RFC 1157 [3] and/or RFC 1905 [4], - the protocol 66 for accessing managed objects. 68 The Framework permits new objects to be defined for the purpose of 69 experimentation and evaluation. 71 1.1. Object Definitions 73 Managed objects are accessed via a virtual information store, termed 74 the Management Information Base or MIB. Objects in the MIB are 75 defined using the subset of Abstract Syntax Notation One (ASN.1) 76 defined in the SMI. In particular, each object type is named by an 77 OBJECT IDENTIFIER, an administratively assigned name. The object 78 type together with an object instance serves to uniquely identify a 79 specific instantiation of the object. For human convenience, we 80 often use a textual string, termed the descriptor, to also refer to 81 the object type. 83 2. Experience with the Interfaces Test Group 85 The ifTestGroup of objects defined in RFC1573 has not been used 86 widely. Some cited problems were: 88 o Few standard tests had been defined to date. 90 o Some well known tests had already been written on a media- 91 specific basis, e.g., DS1 loopback. 93 o The ifTestGroup allowed for interface testing only. 95 o A logging capability was missing. 97 As a result, the ifTestGroup and associated ifTestTable have been 98 deprecated. However, since renewed interest was expressed in a 99 generic testing capability, specifically in the development of MIBs 100 for managing Asynchronous Transfer Mode interfaces, a set of 101 requirements have been defined that form the basis for the design of 102 the generic Test MIB defined in this memo. 104 3. Requirements for a Generic Test MIB 106 This section describes the requirements that have been identified for 107 a generic test MIB. 109 3.1. Test Identification 111 The system defined in RFC1573 to identify tests relies on OBJECT 112 IDENTIFIERs. This system is flexible in that it allows additional 113 tests to be defined over time and autonomously by vendors, removing 114 the need to register test types in a single place. This mechanism for 115 test identification has been retained. 117 3.2. Test Targets 119 With the advent of an increasing number of non-interface related MIB 120 modules it is desirable to define a test capability that allows 121 testing of interfaces and non-interface physical entities. The 122 following possibilities were considered: 124 a) Separate test capabilities for interface tests and other tests. 126 b) The use of a single test capability where the test target would 127 be defined within the test table. 129 This memo uses the latter approach and uses an object with the syntax 130 RowPointer to identify test targets. (Initially, the use of the 131 Entity MIB was considered for identification of test targets, but 132 this was abandoned because this would require support of the Entity 133 MIB for testing purposes.) 135 Tests are listed in the testTable. The entries in the testTable are 136 distinguished through the value of a simple integer called testIndex. 138 3.3. Single Versus Multiple Simultaneous Tests 140 The capability of allowing multiple simultaneous tests has sometimes 141 been described as useful, though the requests for the feature have 142 been sporadic. However, when allowing for non-interface related tests 143 this need may become more apparent. Also, proxy situations may make 144 the ability to run multiple simultaneous tests more desirable. A 145 related question is: how long may a test run? 147 This MIB module has taken a middle road approach where simultaneous 148 tests on different physical entities are possible, while simultaneous 149 tests on a single entity are excluded. This approach avoids the need 150 for more complex read-create tables. A test in progress can be 151 stopped by setting the testType to 'noTest'. 153 3.4. Logging Results 155 A logging capability of test results serves to store the test results 156 for some period of time. Two mechanisms were considered: 158 1) Separate the test capability and the log. 160 2) Combine the test capability and the log in a single table. 162 Note that searching criteria on the log relate to this choice as 163 well. 165 The log length is necessarily limited. The following choices were 166 considered: 168 1) Age the entries. 170 2) Limit by the number of entries. 172 3) A system that allows either 1) or 2). 174 This MIB module chooses a system where the test capability 175 (testTable) has been separated from the log (testLogTable). The log 176 length is limited by a read-write object (testLogMaxSize). 178 This MIB module also defines a notification, testComplete, which 179 contains the same information as the log entry. Therefore, an agent 180 with limited resources can limit the maximum size of the log to a 181 very few number of entries and rely on a management application to 182 receive and log the testComplete notifications. 184 3.5. Log Searching 186 Efficient searching in a log is a key to its effectiveness. The 187 following possibilities were considered: 189 a) Sort on age of the entries. 191 b) Sort on test type. 193 c) Sort on combinations of the above. 195 This MIB module chooses for the index testId, which is an integer 196 identifier for an invocation of a test. This addresses the requests 197 that are expected to be most common: 199 o What is the result of test testId? 201 o What are the results of the last n tests? 203 Since the testId has been defined as monotonically increasing, this 204 approach will order log entries by time, oldest to newest. The 205 possibility of testId wrapping is minimized by having it restart at 0 206 and the log flushed when the agent restarts. When a manager is 207 interested in a specific test, a specific get-request may be issued. 208 When a manager is interested in the latest n tests for the system, 209 getnext/bulk starting from (testId-n) provides the approximate 210 answer. Note that defining testId as a "TestAndDecr" would yield more 211 precise results because the testLogTable would then be sorted with 212 the most recent test first; however this was rejected because of the 213 counter-intuitive behavior of the resulting index and the slight 214 increase in complexity due to this new syntax. 216 3.6. Determining Agent Test Capabilities 218 The testTable will only have entries for those entities represented 219 by this agent that support tests. No capability has been defined to 220 list the tests that an entity is capable of. However, if an entity is 221 only capable of one test, then the testType columnar object for that 222 entity may be initialized to that type, or, if it is capable of many 223 tests, it may be initialized to one of the supported types. 225 4. Definitions 227 TEST-MIB DEFINITIONS ::= BEGIN 229 IMPORTS 230 MODULE-IDENTITY, OBJECT-TYPE, TimeTicks, 231 experimental, NOTIFICATION-TYPE, mib-2 232 FROM SNMPv2-SMI 233 TEXTUAL-CONVENTION, TestAndIncr, AutonomousType, RowPointer 234 FROM SNMPv2-TC 235 MODULE-COMPLIANCE, OBJECT-GROUP 236 FROM SNMPv2-CONF 237 ; 239 testMIB MODULE-IDENTITY 240 LAST-UPDATED "9611251200Z" -- November 25, 1996 241 ORGANIZATION "IETF IFMIB Working Group" 242 CONTACT-INFO 243 "Keith McCloghrie 244 Postal: Cisco Systems 245 170 West Tasman Drive 246 San Jose, CA 95134 247 US 248 Tel: +1 408 526 5260 249 E-mail: kzm@cisco.com 251 Kaj Tesink 252 Postal: Bell Communications Research 253 331 Newman Springs Road 254 Red Bank, NJ 07701 255 US 256 Tel: +1 908 758 5254 257 E-mail: kaj@cc.bellcore.com 259 Maria Greene 260 Postal: Ascom Nexion 261 289 Great Road 262 Acton, MA 01720 263 US 264 Tel: +1 508 266 4570 265 E-mail: greene@nexen.com" 266 DESCRIPTION 267 "This MIB module provides a generic test 268 capability." 269 -- ******** NOTE TO THE RFC EDITOR ************** 270 -- In case this module is put on the standards track 271 -- replace the following: 273 -- "::= {experimental XX}" with 274 -- "::= { mib-2 YY }" 275 ::= { experimental XX } 277 testMIBObjects OBJECT IDENTIFIER ::= { testMIB 1 } 279 HostName ::= TEXTUAL-CONVENTION 280 DISPLAY-HINT "255a" 281 STATUS current 282 DESCRIPTION 283 "This data type is used to model an administratively 284 assigned hostname of the owner of a test. This 285 information is taken from the NVT ASCII character set. 286 It is suggested that this name contain one or more of 287 the following: ASCII form of the manager station's 288 transport address or management station name (e.g., 289 domain name)." 290 SYNTAX OCTET STRING (SIZE(0..255)) 292 -- The Test Table 294 testTable OBJECT-TYPE 295 SYNTAX SEQUENCE OF TestEntry 296 MAX-ACCESS not-accessible 297 STATUS current 298 DESCRIPTION 299 "This table contains one entry per entity that supports 300 testing. It defines objects which allow a network 301 manager to instruct an agent to test an entity for 302 various faults. Tests for an entity are defined in the 303 specific MIB for that entity. After invoking a test, 304 the object testResult can be read to determine the 305 outcome. If an agent can not perform the test, 306 testResult is set to so indicate. The testLogTable can 307 be used to provide further test-specific or entity- 308 specific (or even enterprise-specific) information 309 concerning the outcome of the test. Only one test can 310 be in progress on each entity at any one time. If one 311 test is in progress when another test is invoked, the 312 second test is rejected. Some agents may reject a test 313 when a prior test is active on another entity. 315 Before starting a test, a manager-station must first 316 obtain 'ownership' of the entry in the testTable for the 317 entity to be tested. This is accomplished with the 318 testId and testStatus objects as follows: 320 try_again: 321 get (testId, testStatus) 322 while (testStatus != notInUse) 323 /* 324 * Loop while a test is running or some other 325 * manager is configuring a test. 326 */ 327 short delay 328 get (testId, testStatus) 329 } 331 /* 332 * Is not being used right now -- let's compete 333 * to see who gets it. 334 */ 335 lock_value = testId 337 if ( set (testId = lock_value, testStatus = inUse, 338 testOwner = 'my-IP-address') == FAILURE) 339 /* 340 * Another manager got the testEntry -- go 341 * try again 342 */ 343 goto try_again; 345 /* 346 * I have the lock 347 */ 348 set up any test parameters. 350 /* 351 * This starts the test 352 */ 353 set (testType = test_to_run); 355 wait for test completion by polling testResult 357 when test completes, agent sets testResult 358 agent also sets testStatus = 'notInUse' 360 retrieve test results from the testLog using 361 lock_value as the index 363 A manager station first retrieves the value of the 364 appropriate testId and testStatus objects, periodically 365 repeating the retrieval if necessary, until the value of 366 testStatus is 'notInUse'. The manager station then tries 367 to set the same testId object to the value it just 368 retrieved, the same testStatus object to 'inUse', and the 369 corresponding testOwner object to a value indicating 370 itself. If the set operation succeeds then the manager 371 has obtained ownership of the testEntry, and the value of 372 the testId object is incremented by the agent (per the 373 semantics of TestAndIncr). Failure of the set operation 374 indicates that some other manager has obtained ownership 375 of the testEntry. 377 Once ownership is obtained, any test parameters can be 378 setup, and then the test is initiated by setting 379 testType. On completion of the test, the agent sets 380 testStatus to 'notInUse'. Once this occurs, the manager 381 can retrieve the results. In the (rare) event that the 382 invocation of tests by two network managers were to 383 overlap, then there would be a possibility that the first 384 test's results might be overwritten by the second test's 385 results prior to the first results being read. This 386 unlikely circumstance can be detected by a network 387 manager retrieving testId at the same time as retrieving 388 the test results, and ensuring that the results are for 389 the desired request. 391 If testType is not set within an abnormally long period 392 of time after ownership is obtained, the agent should 393 time-out the manager, and reset the value of the 394 testStatus object back to 'notInUse'. It is suggested 395 that this time-out period be 5 minutes. 397 In general, a management station must not retransmit a 398 request to invoke a test for which it does not receive a 399 response; instead, it properly inspects an agent's MIB to 400 determine if the invocation was successful. Only if the 401 invocation was unsuccessful, is the invocation request 402 retransmitted. 404 Some tests may require the entity to be taken off- line 405 in order to execute them, or may even require the agent 406 to reboot after completion of the test. In these 407 circumstances, communication with the management station 408 invoking the test may be lost until after completion of 409 the test. An agent is not required to support such 410 tests. However, if such tests are supported, then the 411 agent should make every effort to transmit a response to 412 the request which invoked the test prior to losing 413 communication. When the agent is restored to normal 414 service, the results of the test are properly made 415 available in the appropriate objects. Note that this 416 requires that the testIndex value assigned to an entity 417 must be unchanged even if the test causes a reboot. An 418 agent must reject any test for which it cannot, perhaps 419 due to resource constraints, make available at least the 420 minimum amount of information after that test completes." 421 ::= { testMIBObjects 1 } 423 testEntry OBJECT-TYPE 424 SYNTAX TestEntry 425 MAX-ACCESS not-accessible 426 STATUS current 427 DESCRIPTION 428 "An entry containing objects for invoking tests on an 429 entity. There is one testEntry for every entity associated 430 with the agent that supports testing." 431 INDEX { testIndex } 432 ::= { testTable 1 } 434 TestEntry ::= 435 SEQUENCE { 436 testIndex INTEGER, 437 testTarget RowPointer, 438 testId TestAndIncr, 439 testStatus INTEGER, 440 testType AutonomousType, 441 testResult INTEGER, 442 testOwner HostName 443 } 445 testIndex OBJECT-TYPE 446 SYNTAX INTEGER (1..65535) 447 MAX-ACCESS not-accessible 448 STATUS current 449 DESCRIPTION 450 "The index of this table." 451 ::= { testEntry 1 } 453 testTarget OBJECT-TYPE 454 SYNTAX RowPointer 455 MAX-ACCESS read-write 456 STATUS current 457 DESCRIPTION 458 "The target of the test. An example of a test target is an 459 instance of an interface, identified by the OID 460 'ifIndex.17'." 461 ::= { testEntry 2 } 463 testId OBJECT-TYPE 464 SYNTAX TestAndIncr 465 MAX-ACCESS read-write 466 STATUS current 467 DESCRIPTION 468 "This object identifies the current invocation of any test, 469 not just tests on the entity identified by the index of this 470 entry. If the agent is restarted the value of this object 471 shall be set to 0. If the value of testId ever reaches its 472 maximum value of 2147483647, it will latch at that value and 473 return the error 'inconsistentValue' (for SNMPv2) or 474 'badValue' (for SNMPv1) if the manager attempts to set it. 476 Note that the value the manager sets this object to when 477 setting the testStatus to 'inUse(2)' is the value that 478 should be used for testLogIndex to retrieve the results of 479 the test. After a successful SET, all instances of testId 480 for all entries in this table will be incremented. 482 The reason the testId and testStatus objects are not outside 483 the table is that this would limit the manager to only 484 running one test at a time." 485 ::= { testEntry 3 } 487 testStatus OBJECT-TYPE 488 SYNTAX INTEGER { notInUse(1), inUse(2) } 489 MAX-ACCESS read-write 490 STATUS current 491 DESCRIPTION 492 "This object indicates whether or not some manager currently 493 has the necessary 'ownership' required to invoke a test on 494 this entity. A write to this object is only successful when 495 it changes its value from 'notInUse(1)' to 'inUse(2)'. 496 After completion of a test, the agent resets the value back 497 to 'notInUse(1)'." 498 ::= { testEntry 4 } 500 testType OBJECT-TYPE 501 SYNTAX AutonomousType 502 MAX-ACCESS read-write 503 STATUS current 504 DESCRIPTION 505 "A control variable used to start and stop operator- 506 initiated entity tests. Most OBJECT IDENTIFIER values 507 assigned to tests are defined elsewhere, in association with 508 specific types of entity. However, this memo defines the 509 special meanings of the subject identifier: 511 noTest OBJECT IDENTIFIER ::= { 0 0 } 513 When the value 'noTest' is written to this object, no action 514 is taken unless a test is in progress, in which case the 515 test is aborted. Writing any other value to this object is 516 only valid when no test is currently in progress, in which 517 case the indicated test is initiated. 519 When read, this object always returns the most recent value 520 that testType was set to. If it has not been set since the 521 last initialization of the network management subsystem on 522 the agent, either a value of or a value of one of the valid 523 test types that can be performed on this entity is 524 returned." 525 ::= { testEntry 5 } 527 testResult OBJECT-TYPE 528 SYNTAX INTEGER { 529 none(1), -- no test yet requested 530 success(2), 531 inProgress(3), 532 notSupported(4), 533 unAbleToRun(5), -- due to state of system 534 aborted(6), 535 failed(7) 536 } 537 MAX-ACCESS read-only 538 STATUS current 539 DESCRIPTION 540 "This object contains the result of the most recently 541 requested test, or the value 'none(1)' if no tests have been 542 requested since the last reset." 543 ::= { testEntry 6 } 545 testOwner OBJECT-TYPE 546 SYNTAX HostName 547 MAX-ACCESS read-write 548 STATUS current 549 DESCRIPTION 550 "The manager which currently has the 'ownership' 551 required to invoke a test on this entity." 552 ::= { testEntry 7 } 554 -- Log size 556 testLogMaxSize OBJECT-TYPE 557 SYNTAX INTEGER (10..2147483647) 558 MAX-ACCESS read-write 559 STATUS current 560 DESCRIPTION 561 "The maximum number entries in the testLogTable. When the 562 table reaches this size the oldest entries will be discarded 563 when new entries are added. The table is flushed when the 564 agent is reset." 565 ::= { testMIBObjects 2 } 567 -- Test Logging Table 569 testLogTable OBJECT-TYPE 570 SYNTAX SEQUENCE OF TestLogEntry 571 MAX-ACCESS not-accessible 572 STATUS current 573 DESCRIPTION 574 "This table contains the most recent test results for tests 575 which completed with the testResult of either 'success(2)' 576 or 'failed(7)'." 577 ::= { testMIBObjects 3 } 579 testLogEntry OBJECT-TYPE 580 SYNTAX TestLogEntry 581 MAX-ACCESS not-accessible 582 STATUS current 583 DESCRIPTION 584 "Each entry in this table represents a test result." 585 INDEX { testLogIndex } 586 ::= { testLogTable 1 } 588 TestLogEntry ::= 589 SEQUENCE { 590 testLogIndex INTEGER, 591 testLogType AutonomousType, 592 testLogCompletionTime TimeTicks, 593 testLogSummary INTEGER, 594 testLogCode OBJECT IDENTIFIER, 595 testLogOwner HostName, 596 testLogTestIndex INTEGER 597 } 599 testLogIndex OBJECT-TYPE 600 SYNTAX INTEGER (1..2147483647) 601 MAX-ACCESS not-accessible 602 STATUS current 603 DESCRIPTION 604 "An integer index that uniquely identifies the entry in the 605 log. This is the value of testId for the completed test." 606 ::= { testLogEntry 1 } 608 testLogType OBJECT-TYPE 609 SYNTAX AutonomousType 610 MAX-ACCESS read-only 611 STATUS current 612 DESCRIPTION 613 "The type of test that has completed." 614 ::= { testLogEntry 2 } 616 testLogCompletionTime OBJECT-TYPE 617 SYNTAX TimeTicks 618 MAX-ACCESS read-only 619 STATUS current 620 DESCRIPTION 621 "The value of sysUpTime when the test completed." 622 ::= { testLogEntry 3 } 624 testLogSummary OBJECT-TYPE 625 SYNTAX INTEGER { 626 success(2), 627 failed(7) 628 } 629 MAX-ACCESS read-only 630 STATUS current 631 DESCRIPTION 632 "The summary result of this test." 633 ::= { testLogEntry 4 } 635 testLogCode OBJECT-TYPE 636 SYNTAX OBJECT IDENTIFIER 637 MAX-ACCESS read-only 638 STATUS current 639 DESCRIPTION 640 "This object contains a code which contains more specific 641 information on the test result, for example an error-code 642 after a failed test. Error codes and other values this 643 object may take are specific to the type of entity and/or 644 test. The value may have the semantics of either the 645 AutonomousType or VariablePointer textual conventions as 646 defined in RFC 1903. The identifier: 648 testCodeUnknown OBJECT IDENTIFIER ::= { 0 0 } 650 is defined for use if no additional result code is 651 available." 652 ::= { testLogEntry 5 } 654 testLogOwner OBJECT-TYPE 655 SYNTAX HostName 656 MAX-ACCESS read-only 657 STATUS current 658 DESCRIPTION 659 "The name of the host that owned the test." 660 ::= { testLogEntry 6 } 662 testLogTestIndex OBJECT-TYPE 663 SYNTAX INTEGER (1..65535) 664 MAX-ACCESS read-only 665 STATUS current 666 DESCRIPTION 667 "The value of testIndex for this test." 668 ::= { testLogEntry 7 } 670 -- Notifications 672 testMIBNotifications OBJECT IDENTIFIER ::= { testMIB 0 } 674 testComplete NOTIFICATION-TYPE 675 OBJECTS { 676 testLogIndex, 677 testLogType, 678 testLogSummary, 679 testLogCode, 680 testLogOwner, 681 testLogTestIndex 682 } 683 STATUS current 684 DESCRIPTION 685 "A testComplete trap signifies that a test has completed for 686 a particular entity. If the testLogCode has the semantics of 687 a VariablePointer, the variable it points at will also be 688 included in the objects list." 689 ::= { testMIBNotifications 1 } 691 -- Conformance Information 692 testMIBConformance OBJECT IDENTIFIER ::= { testMIB 3 } 694 testMIBGroups OBJECT IDENTIFIER 695 ::= { testMIBConformance 1 } 697 testMIBCompliances OBJECT IDENTIFIER 698 ::= { testMIBConformance 2 } 700 -- Compliance Statements 702 testMIBCompliance MODULE-COMPLIANCE 703 STATUS current 704 DESCRIPTION 705 "The compliance statement for SNMP agents which support generic 706 testing capabilities." 708 MODULE -- this module 710 MANDATORY-GROUPS { testMIBGroup } 712 OBJECT testLogMaxSize 713 MIN-ACCESS read-only 714 DESCRIPTION 715 "Write access is not required." 717 ::= { testMIBCompliances 1 } 719 -- Units of Conformance 721 testMIBGroup OBJECT-GROUP 722 OBJECTS { 723 testTarget, 724 testId, 725 testStatus, 726 testType, 727 testResult, 728 testOwner, 729 testLogType, 730 testLogMaxSize, 731 testLogCompletionTime, 732 testLogSummary, 733 testLogCode, 734 testLogOwner, 735 testLogTestIndex 736 } 737 STATUS current 738 DESCRIPTION 739 "A collection of objects providing a generic 740 test capability." 741 ::= { testMIBGroups 1 } 743 END 744 5. Usage Examples 746 The following sections show examples of interface testing and system 747 testing. These examples assume the following physical configuration 748 represented using the Entity MIB [5] and that, for convenience, the 749 agent uses the value of entPhysicalIndex for testIndex. Note that 750 this is just a convenience for an agent that supports both the Entity 751 MIB and the Test MIB and is not a requirement. 753 A router containing two slots. Each slot contains a 3 port 754 router/bridge module. Each port is also represented in the ifTable. 756 Physical entities -- entPhysicalTable: 757 1 chassis: 758 entPhysicalDescr.1 == "Acme Chassis Model 100" 759 entPhysicalVendorType.1 == acmeProducts.chassisTypes.1 760 entPhysicalContainedIn.1 == 0 761 entPhysicalClass.1 == chassis(3) 762 entPhysicalParentRelPos.1 == 0 764 2 slots within the chassis: 765 entPhysicalDescr.2 == "Acme Router Chassis Slot 1" 766 entPhysicalVendorType.2 == acmeProducts.slotTypes.1 767 entPhysicalContainedIn.2 == 1 768 entPhysicalClass.2 == container(5) 769 entPhysicalParentRelPos.2 == 1 771 entPhysicalDescr.3 == "Acme Router Chassis Slot 2" 772 entPhysicalVendorType.3 == acmeProducts.slotTypes.1 773 entPhysicalContainedIn.3 == 1 774 entPhysicalClass.3 == container(5) 775 entPhysicalParentRelPos.3 == 2 777 2 Field-replaceable modules: 778 Slot 1 contains a module with 3 ports: 779 entPhysicalDescr.4 == "Acme Router Module Model 10" 780 entPhysicalVendorType.4 == acmeProducts.moduleTypes.14 781 entPhysicalContainedIn.4 == 2 782 entPhysicalClass.4 == module(9) 783 entPhysicalParentRelPos.4 == 1 785 entPhysicalDescr.5 == "Acme Router Ethernet Port 1" 786 entPhysicalVendorType.5 == acmeProducts.portTypes.2 787 entPhysicalContainedIn.5 == 4 788 entPhysicalClass.5 == port(10) 789 entPhysicalParentRelPos.5 == 1 790 entPhysicalDescr.6 == "Acme Router Ethernet Port 2" 791 entPhysicalVendorType.6 == acmeProducts.portTypes.2 792 entPhysicalContainedIn.6 == 4 793 entPhysicalClass.6 == port(10) 794 entPhysicalParentRelPos.6 == 2 796 entPhysicalDescr.7 == "Acme Router Ethernet Port 3" 797 entPhysicalVendorType.7 == acmeProducts.portTypes.3 798 entPhysicalContainedIn.7 == 4 799 entPhysicalClass.7 == port(10) 800 entPhysicalParentRelPos.7 == 3 802 Slot 2 contains another 3-port module: 803 entPhysicalDescr.8 == "Acme Router Module Model 11" 804 entPhysicalVendorType.8 == acmeProducts.moduleTypes.15 805 entPhysicalContainedIn.8 == 3 806 entPhysicalClass.8 == module(9) 807 entPhysicalParentRelPos.8 == 1 809 entPhysicalDescr.9 == "Acme Router Fddi Port 1" 810 entPhysicalVendorType.9 == acmeProducts.portTypes.3 811 entPhysicalContainedIn.9 == 8 812 entPhysicalClass.9 == port(10) 813 entPhysicalParentRelPos.9 == 1 815 entPhysicalDescr.10 == "Acme Router Ethernet Port 2" 816 entPhysicalVendorType.10 == acmeProducts.portTypes.2 817 entPhysicalContainedIn.10 == 8 818 entPhysicalClass.10 == port(10) 819 entPhysicalParentRelPos.10 == 2 821 entPhysicalDescr.11 == "Acme Router Ethernet Port 3" 822 entPhysicalVendorType.11 == acmeProducts.portTypes.2 823 entPhysicalContainedIn.11 == 8 824 entPhysicalClass.11 == port(10) 825 entPhysicalParentRelPos.11 == 3 827 Entities Supporting Tests -- testTable: 828 testTarget.4 == entPhysicalIndex.4 829 testTarget.5 == ifIndex.17 830 testTarget.6 == ifIndex.18 831 testTarget.7 == ifIndex.19 832 testTarget.8 == entPhysicalIndex.8 833 testTarget.9 == ifIndex.3 834 testTarget.10 == ifIndex.4 835 testTarget.11 == ifIndex.5 837 5.1. Interface Test 839 In this example, the network manager wishes to run a loopback test on 840 the third Ethernet port on the module in slot 1. The testIndex of the 841 port is 7. The Ethernet-like Interfaces MIB [6], defines an OBJECT 842 IDENTIFIER for the dot3TestLoopBack. 844 The test would be invoked as follow: 845 try_again: 846 get (testId.7, testStatus.7) 847 while (testStatus != notInUse) 848 /* 849 * Loop while a test is running or some other 850 * manager is configuring a test. 851 */ 852 short delay 853 get (testId.7, testStatus.7) 854 } 856 /* 857 * Is not being used right now -- let's compete 858 * to see who gets it. 859 */ 860 lock_value = testId 862 if ( set (testId.7 = lock_value, testStatus.7 = inUse, 863 testOwner.7 = 'my-IP-address') == FAILURE) 864 /* 865 * Another manager got the testEntry -- go 866 * try again 867 */ 868 goto try_again; 870 /* 871 * I have the lock 872 */ 873 set up any test parameters. 875 /* 876 * This starts the test 877 */ 878 set (testType.7 = dot3TestLoopBack); 880 wait for test completion by polling testResult.7 882 when test completes, agent sets testResult 883 agent also sets testStatus = 'notInUse' 885 retrieve any additional test results from 886 testLogTable using lock_value as the index 888 5.2. System Test 890 A system test is the same as an interface test from the perspective 891 of the test table. For example, the network administrator may wish to 892 run a self test on the module in slot 2. 894 Let's assume such a test is defined in one of the Acme vendor's 895 enterprise MIBs as follows: 896 acmeModuleSelfTest OBJECT-IDENTITY 897 STATUS current 898 DESCRIPTION 899 "Run a diagnostic self-test on an Acme hardware 900 module." 901 ::= { acmeProductsTestTypes 1 } 903 The procedure of invoking the test and retrieving the results is the 904 same as that described in the Interface Test example. Note that value 905 of entPhysicalIndex for the module in slot 2 is 8 based on the 906 earlier example configuration so the test would be started using this 907 operation: 908 /* 909 * This starts the test 910 */ 911 set(testType.8 = acmeModuleSelfTest); 913 6. Acknowledgments 915 This document is a product of the IETF's Interfaces MIB Working 916 Group. 918 The original ifTestTable was the work of Keith McCloghrie (Cisco) and 919 Frank Kastenholz (FTP Software) and has been used almost unchanged in 920 this further evolution. 922 The authors would like to acknowledge the following individuals for 923 their input on requirements: 925 James Watt (Newbridge) 926 Dave Fowler (Newbridge) 927 Steven Buchko (Newbridge) 928 Milt Rosslinsky (ACC) 930 7. References 932 [1] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and 933 S. Waldbusser, "Structure of Management Information for Version 2 934 of the Simple Network Management Protocol (SNMPv2)", RFC1902, SNMP 935 Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., 936 International Network Services, January 1996. 938 [2] McCloghrie, K., and M. Rose, Editors, "Management Information Base 939 for Network Management of TCP/IP-based internets: MIB-II", STD 17, 940 RFC 1213, Hughes LAN Systems, Performance Systems International, 941 March 1991. 943 [3] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network 944 Management Protocol", RFC 1157, SNMP Research, Performance Systems 945 International, Performance Systems International, MIT Laboratory 946 for Computer Science, May 1990. 948 [4] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and 949 S. Waldbusser, "Protocol Operations for Version 2 of the Simple 950 Network Management Protocol (SNMPv2)", RFC1905, SNMP Research,Inc., 951 Cisco Systems, Inc., Dover Beach Consulting, Inc., International 952 Network Services, January 1996. 954 [5] McCloghrie, K., and A. Bierman, Editors, "Entity MIB", RFC2037, 955 Cisco Systems, January 1996. 957 [6] Kastenholz, F., "Definitions of Managed Objects for the Ethernet- 958 like Interface Types using SMIv2", RFC1650, FTP Software, Inc, 959 August 1994. 961 [6] McCloghrie, K., Kastenholz, F., "Evolution of the Interfaces Group 962 of MIB-II", RFC1573, (should be updated to new IF-MIB RFC#) Cisco 963 Systems, Inc., FTP Software, January 1994. 965 [7] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and 966 S. Waldbusser, "Textual Conventions for Version 2 of the Simple 967 Network Management Protocol (SNMPv2)", RFC1903, SNMP Research,Inc., 968 Cisco Systems, Inc., Dover Beach Consulting, Inc., International 969 Network Services, January 1996. 971 8. Security Considerations 973 Security issues are not discussed in this memo. 975 9. Authors' Addresses 977 Maria Greene 978 Ascom Nexion 979 289 Great Road 980 Acton, MA 01720-4739 981 Phone: (508) 266-4570 982 EMail: greene@nexen.com 984 Keith McCloghrie 985 Cisco Systems 986 170 West Tasman Drive 987 San Jose, CA 95134 988 Phone: (408) 526-5260 989 E-mail: kzm@cisco.com 991 Kaj Tesink 992 Bell Communications Research 993 Room 1A-427 994 331 Newman Springs Road 995 P.O. Box 7020 996 Red Bank, NJ 07701-7020 997 Phone: (908) 758-5254 998 EMail: kaj@cc.bellcore.com 1000 Table of Contents 1002 1 The SNMP Network Management Framework ........................ 2 1003 1.1 Object Definitions ......................................... 2 1004 2 Experience with the Interfaces Test Group .................... 3 1005 3 Requirements for a Generic Test MIB .......................... 3 1006 3.1 Test Identification ........................................ 3 1007 3.2 Test Targets ............................................... 4 1008 3.3 Single Versus Multiple Simultaneous Tests .................. 4 1009 3.4 Logging Results ............................................ 5 1010 3.5 Log Searching .............................................. 5 1011 3.6 Determining Agent Test Capabilities ........................ 6 1012 4 Definitions .................................................. 7 1013 5 Usage Examples ............................................... 19 1014 5.1 Interface Test ............................................. 21 1015 5.2 System Test ................................................ 23 1016 6 Acknowledgments .............................................. 23 1017 7 References ................................................... 24 1018 8 Security Considerations ...................................... 25 1019 9 Authors' Addresses ........................................... 25