idnits 2.17.1 draft-ietf-trunkmib-dds-mib-00.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-04-26) 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 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 8 longer pages, the longest (page 2) being 59 lines 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 is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** There are 2 instances of lines with control characters in the document. ** The abstract seems to contain references ([TBD]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 209 has weird spacing: '...Present true(...' == Line 235 has weird spacing: '...ifIndex ifTyp...' == Line 281 has weird spacing: '...ifIndex ifTyp...' == Line 332 has weird spacing: '...ifIndex ifTyp...' -- 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 (April 1996) is 10238 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) -- Looks like a reference, but probably isn't: 'TBD' on line 203 == Unused Reference: '5' is defined on line 898, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 908, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 916, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 919, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 922, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1442 (ref. '1') (Obsoleted by RFC 1902) ** Downref: Normative reference to an Historic RFC: RFC 1445 (ref. '3') ** Obsolete normative reference: RFC 1448 (ref. '4') (Obsoleted by RFC 1905) ** Downref: Normative reference to an Historic RFC: RFC 1157 (ref. '5') -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '11' Summary: 15 errors (**), 0 flaws (~~), 12 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT DDS MIB April 1996 4 Definitions of Managed Objects for DDS Interface Types 6 Mon Apr 8 9:00:00 EST 1996 7 Expires: October 13, 1996 9 draft-ietf-trunkmib-dds-mib-00.txt 11 Mark A. Cotton 12 Eastern Research, Inc. 13 mcotton@erinc.com 15 Status of this Memo 17 This document is an Internet-Draft. Internet-Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its areas, 19 and its working groups. Note that other groups may also distribute 20 working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as ``work in progress.'' 27 To learn the current status of any Internet-Draft, please check the 28 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 29 Directories on ds.internic.net (US East Coast), nic.nordu.net 30 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 31 Rim). 33 Abstract 35 This memo defines a portion of the Management Information Base (MIB) 36 for use with network management protocols in TCP/IP-based internets. 37 In particular, it defines objects for managing Digital Data System 38 (DDS) interfaces. Along with the Definition of Managed Objects for 39 RS-232-like Hardware Devices using SMIv2 [TBD], this memo also pro- 40 vides basic management capabilities for DDS DSU/CSU-like interfaces. 42 This memo specifies a MIB module in a manner that is both compliant 43 to the SNMPv2 SMI, and semantically identical to the peer SNMPv1 45 Expires October 1996 [Page 1] 46 definitions. 48 Introduction 50 This document reflects work being done by the trunk-mib working 51 group (trunk-mib@cisco.com). This document defines a MIB that allows 52 DDS-type interfaces to be managed via SNMP. This is an attempt 53 to ensure that SNMP compliant DDS devices have a common MIB. 54 An attempt has been made to include devices which support DDS 55 secondary channel capability. This document is intended to allow 56 for the SNMP managment of the basic DDS CSU/DSU, with and without 57 rate adaption. 59 Table of Contents 61 1. The SNMPv2 Network Management Framework ............... 2 62 2. Objects ............................................... 2 63 2.1 Format of Definitions ................................ 3 64 3. Overview .............................................. 3 65 3.1 Binding between ifIndex and DDS Interfaces ........... 8 66 3.2 DDS Terminology ...................................... 8 67 3.3 DDS Statistics and Diagnostics ....................... 8 68 3.3.1 Performance and Availability ....................... 8 69 3.3.2 Network Alarms and Status Conditions ............... 9 70 3.3.3 Network Control Codes .............................. 9 71 3.3.4 Loopbacks and Their Methods ........................ 9 72 3.3.4.1 Non-Latching Loopbacks ........................... 9 73 3.3.4.2 Latching Loopbacks ............................... 9 74 4. Definitions ........................................... 10 75 4.1 DDS Configuration Table .............................. 11 76 4.2 DDS Diagnostics Table ................................ 13 77 4.4 DDS Statistics Table ................................. 15 78 4.5 DDS Interface Group .................................. 17 79 4.6 DDS Interface Compliance ............................. 18 80 5. Acknowledgements ...................................... 18 81 6. References ............................................ 19 82 7. Security Considerations ............................... 20 83 8. Author's Address ...................................... 20 85 1. The SNMPv2 Network Management Framework 87 The SNMPv2 Network Management Framework consists of four major 88 components. They are: 90 o RFC 1442 [1] which defines the SMI, the mechanisms used for 91 describing and naming objects for the purpose of management. 93 Expires October 1996 [Page 2] 94 o STD 17, RFC 1213 [2] defines MIB-II, the core set of managed 95 objects for the Internet suite of protocols. 97 o RFC 1445 [3] which defines the administrative and other 98 architectural aspects of the framework. 100 o RFC 1448 [4] which defines the protocol used for network 101 access to managed objects. 103 The Framework permits new objects to be defined for the purpose of 104 experimentation and evaluation. 106 2. Objects 108 Managed objects are accessed via a virtual information store, termed 109 the Management Information Base or MIB. Objects in the MIB are 110 defined using the subset of Abstract Syntax Notation One (ASN.1) [6] 111 defined in the SMI. In particular, each object has a name, a syntax, 112 and an encoding. The name is an object identifier, an 113 administratively assigned name, which specifies an object type. The 114 object type together with an object instance serves to uniquely 115 identify a specific instantiation of the object. For human 116 convenience, we often use a textual string, termed the OBJECT 117 DESCRIPTOR, to also refer to the object type. 119 2.1. Format of Definitions 121 Section 4 contains contains the specification of all object types 122 contained in this MIB module. The object types are defined using the 123 conventions defined in the SMI, as amended by the extensions that 124 are specified in RFC1442 [1], RFC1445 [3], and RFC1448 [4]. 126 3. Overview 128 This document defines managed objects for a Digital Dataphone Service 129 (DDS) interface. At present these objects apply to an interface 130 with an ifType value dds (TBD). 132 Editors note: The ifType value dds needs to be allocated by the IANA 133 prior to this memo's publication. 135 The following diagram shows the various internal organization of 137 Expires October 1996 [Page 3] 138 a typical DDS DSU/CSU. 140 +--------------------------+-----------------------+---+ 141 | | | | 142 | D DSU section | CSU section | D | 143 V.35,| a | | D | N 144 RS232,| t | | S | E 145 or | a It is this section | This section of the | | T 146 RS530 | that would be resp- | unit is responsible | i | W 147 inter-| i onsible for the rate | for the loop rate and | n | O 148 face | n adaption and the de- | the detection of all | t | R 149 | t tection of the V.54 | network loop codes, | e | K 150 (DTE) | e loopback pattern. | even for that of the | r | 151 | r | DSU loopbacks. These | f | 152 | f | are the XOV codes that| a | 153 | a | are outlined in AT&T | c | 154 | c | TR62310. | e | 155 | e | | | 156 | | | | 157 +--------------------------+-----------------------+---+ 159 The MIB contained herein describes objects for the management of 160 configuration, diagnostics, alarms, and statistics related to DDS 161 DSU/CSUs. These definitions are based on the AT&T DS0 Local Digital 162 Channel Description and Interface Specification (TR 62310 [8]). 164 The objects defined in this memo provide instrumentation for the 165 Network Interface. The instrumentation for the Data Interface, is 166 provided by the managed objects for the given type of interface, 167 e.g. RFC 1695 [TBD] for the case where the Data Interface is an 168 RS-232-like interface or RFC TBD [TBD] for the case where the Data 169 interface is a DS0 on a DS0-like interface. 171 A interface with the ifType of dds(TBD) implements the ifGeneral 172 group defined in the IF-MIB [TBD] and uses the standard interfaces 173 objects as follows: 175 ifTable Object Use for DDS Interfaces 176 -------------- ------------------------------------------- 177 ifIndex Interface index. 179 ifDescr As per the interfaces MIB [TBD] 181 ifType dds(TBD) 183 ifSpeed The speed at which the DDS interface 184 is operating. This is the same as 185 the value in ddsPrimaryChannelSpeed 186 except when it has a value of 64 kbits/s. 188 Expires October 1996 [Page 4] 189 In that case, ifSpeed will have a value 190 of 72 kbits/s 192 ifPhysAddress The value of the Circuit Identifier assigned 193 by the service provider. If there is no 194 value assigned, this object should have 195 a length of zero.. 197 ifAdminStatus As per the Interfaces MIB [TBD] 199 ifOperStatus As per the Interfaces MIB [TBD] 201 ifLastChange As per the Interfaces MIB [TBD] 203 ifName As per the interfaces MIB [TBD]. 205 ifLinkUpDownTrapEnable Set to enabled(1). 207 ifHighSpeed Zero (the maximum line speed is 72 kbits/s). 209 ifConnectorPresent true(1) 211 The following diagram demonstrates how an SNMP managable DDS DSU/CSU 212 shelf could be connected to a router to allow the router WANs 213 access to the DDS circuits. 215 +-----+ 216 | | | R interface Network i/f 217 |E | | +---------------------+ 218 |t | R | 56KBPS | Line#A | DDS Circuit 219 |h | |---------------+ - - - - - - - - - +------> 220 |e | O | | | 221 |r | | 64KBPS | Line#B | DDS Circuit 222 |n | U |---------------+ - - - - - - - - - - +------> 223 |e | | | DDS DSU/CSU Shelf | 224 |t | T | 9600BPS | Line#C | DDS Circuit 225 | | |---------------+ - - - -- -- - - - - +------> 226 |-----+ E | | | 227 | | | 19200BPS | Line#D | DDS Circuit 228 |L | R |---------------+ - - - - -- - - - - +------> 229 |A | | |_____________________| 230 |N | | 231 | +-----+ 233 The assignment of the index values could for example be: 235 ifIndex ifType Description 237 Expires October 1996 [Page 5] 238 ------- --------- -------------------------- 239 1 rs232(33) Line A - Data Interface 240 2 rs232(33) Line B - Data Interface 241 3 dds (TBD) Line A - Network Interface 242 4 dds (TBD) Line B - Network Interface 243 5 rs232(33) Line C - Data Interface 244 6 dds (TBD) Line C - Network Interface 245 7 rs232(33) Line D - Data Interface 246 8 dds (TBD) Line D - Network Interface 247 9 rs232(33) Router 248 10 rs232(33) Router 249 11 rs232(33) Router 250 12 rs232(33) Router 251 13 ethernetCsmaCd Ethernet port 253 For this example, ifNumber is equal to 13. Note the following 254 description of ifIndex: it describes ports on the managed device. 255 In this example, some ports are RS-232-like interfaces, some are 256 DDS-like interfaces, some are RS-232-like interfaces that are not 257 associated with the DDS DSU/CSU lines, and there is one port which 258 is the ethernet port on the device. 260 The relationship between the Data Interface and the corresponding 261 Network Interface is captured in the ifStackTable. 263 ifStackTable Entries for proxy-managed DSU/CSU shelf: 265 Higher Layer Lower Layer 266 1 3 267 2 4 268 5 6 269 7 8 270 9 1 271 10 2 272 11 5 273 12 7 275 If the DSU/CSU shelf is managed by itself by a local SNMP Agent, that 276 is to say not managed by the router-based agent, the situation would 277 be as follows. 279 The assignment of the index values could for example be: 281 ifIndex ifType Description 282 ------- --------- -------------------------- 283 1 dds (TBD) Line A - Network Interface 284 2 rs232(33) Line A - Data Interface 285 3 dds (TBD) Line B - Network Interface 286 4 rs232(33) Line B - Data Interface 288 Expires October 1996 [Page 6] 289 5 dds (TBD) Line C - Network Interface 290 6 rs232(33) Line C - Data Interface 291 7 dds (TBD) Line D - Network Interface 292 8 rs232(33) Line D - Data Interface 294 Again, the relationship between the Data Interface and the 295 corresponding Network Interface is captured in the ifStackTable. 297 ifStackTable Entries for directly-managed DSU/CSU shelf: 299 Higher Layer Lower Layer 300 2 1 301 4 3 302 6 5 303 8 7 305 The next diagram demonstrates how an SNMP managable CSU might 306 be integrated within the router itself. 308 +-----+---------------------+ 309 | | | | Network interfaces 310 | | | DDS CSU | 311 |E | | Line#A | DDS Circuit 312 |t | R + - - - - - - - - - +-------------------> 313 |h | | DDS CSU | 314 |e | O | Line#B | DDS Circuit 315 |r | + - - - - - - - - - - +-------------------> 316 |n | U | DDS CSU | 317 |e | | Line#C | DDS Circuit 318 |t | T + - - - -- -- - - - - +-------------------> 319 | | | DDS CSU | 320 |-----| E | Line#D | DDS Circuit 321 | | + - - - - -- - - - - +-------------------> 322 |L | R | | 323 |A | | DDS CSU | DDS Circuit 324 |N | | Line#E +-------------------> 325 +-----+---------------------+ 327 If the DDS CSUs are integrated within the router itself, the interface 328 organization might be as follows. 330 The assignment of the index values could for example be: 332 ifIndex ifType Description 333 ------- --------- -------------------------- 334 1 dds (TBD) Line A - Network Interface 335 2 dds (TBD) Line B - Network Interface 337 Expires October 1996 [Page 7] 338 3 dds (TBD) Line C - Network Interface 339 4 dds (TBD) Line D - Network Interface 340 5 dds (TBD) Line E - Network Interface 341 6 ethernetCsmaCd Ethernet port 343 In this example, there is no Data Interface present, because the 344 Network Interfaces terminate within the router. The ifStackTable 345 entries would only show these Network Interfaces alone. 347 ifStackTable Entries for a router with integral CSUs: 349 Higher Layer Lower Layer 350 1 1 351 2 2 352 3 3 353 4 4 355 3.1. Binding between ifIndex and DDS Interfaces 357 For DDS circuits with the secondary channel activated, it is at 358 the present time unclear how these interfaces will be accessed. 359 Certainly they are capable of being managed via RFC1659, however 360 the binding between the actual interface and an ifIndex that is 361 representative of that interface has not yet been determined. 363 3.2. DDS Terminology 365 The terms used in this document, that describe the line conditions 366 of a DDS interface, come from AT&T's technical reference document 367 TR62310 - DS0 Digital Local Channel Description and Interface 368 Specification [8]. 370 3.3. DDS Statistics and Diagnostics 372 The next sections describe the alarms and diagnostics which directly 373 pertain to DDS DSU/CSUs, as per AT&T TR 62310 [8]. 375 3.3.1 Performance and Availability 377 The performance terms used are Errored Seconds (ES), Error-Free 378 Seconds (EFS), and Severely Errored Seconds (SES). 380 An Errored Second is any second during which at least one bit was 381 in error. 383 Expires October 1996 [Page 8] 384 An Error-Free Second is a second during which there were no bits 385 in error. 387 A Severely Errored Second is a second during which the error 388 threshold of 1x10^-3 was exceeded. 390 3.3.2 Network Alarms and Status Conditions 392 When a failure occurs in the network, the network will forward a 393 control code (possibly abnormal station code - ASC) toward the CSU 394 at the customer interface. The exact codes transmitted and the 395 conditions necessary for their generation are detailed in section 396 5.3 (page 11) of AT&T TR 62310 [8]. 398 3.3.3 Network Control Codes 400 Table 5.3 on page 13 of AT&T TR 62310 specifies the Network Control 401 codes in detail. A further discussion of the nature of the codes 402 is not warranted here. 404 3.3.4 DDS Interface Loopbacks and Their Methods 406 The two loopbacks defined by TR 62310 [8] are CSU loopback and DSU 407 loopback. The CSU loopback is intended to loop the network 408 connection back to itself as close as is possible to the network 409 interface (NI). The DSU loopback is usually implemented as a 410 bidirectional loop located a close as possible to the DTE side 411 of the CSU/DSU. 413 These loopbacks may be activated by either a non-latching method 414 or latching method. 416 3.3.4.1 Non-Latching Loopbacks 418 The non-latching loopback is activated when the network sends a 419 loop-code byte alternated with a test pattern byte. The loop 420 must start after the detection of four consecutive bytes of the 421 loop code (CSU or DSU) and remain engaged until five consecutive 422 bytes are received without the loop code. The loop codes must be 423 replaced with a return-code when looped back toward the network. 424 This is used to synchronize the test pattern detector. 426 3.3.4.2 Latching Loopbacks 428 Expires October 1996 [Page 9] 429 Latching loops are named such because a pattern is sent from the 430 network to the CSU/DSU to cause a loopback condition which will 431 remain in effect once the pattern has ceased. On page 17 of 432 TR 62310 [8], the sequence for activating the latching loopbacks 433 are described in detail. 435 4. Definitions 437 DDS-MIB DEFINITIONS ::= BEGIN 438 IMPORTS 439 MODULE-IDENTITY, OBJECT-TYPE, Counter32 440 FROM SNMPv2-SMI 441 MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF 442 TruthValue, TimeStamp FROM SNMPv2-TC 443 ifIndex FROM IF-MIB 444 experimental FROM RFC1213-MIB; 446 -- this is the MIB module for the DDS objects 448 ddsMIB MODULE-IDENTITY 449 LAST-UPDATED "9604080900Z" 450 ORGANIZATION "IETF Trunk MIB Working Group" 451 CONTACT-INFO 452 " Mark A. Cotton 453 Postal: Eastern Research, Inc. 454 225 Executive Drive 455 Moorestown, NJ 08057 456 Tel: 609-273-6622 457 Fax: 609-273-1847 458 E-mail: mcotton@erinc.com" 459 DESCRIPTION 460 "The MIB module for Digital Dataphone Service 461 DSU/CSU-like hardware devices." 462 ::= { experimental 99 } 464 ddsObjects OBJECT IDENTIFIER ::= { ddsMIB 1 } 465 ddsGroups OBJECT IDENTIFIER ::= { ddsMIB 2 } 466 ddsCompliances OBJECT IDENTIFIER ::= { ddsMIB 3 } 468 -- The DDS Objects consists of three tables: 469 -- 470 -- DDS Configuration 471 -- DDS Diagnostics 472 -- DDS Statistics 473 -- *************************** 474 -- the DDS Configuration Table 475 -- *************************** 477 ddsConfigTable OBJECT-TYPE 478 SYNTAX SEQUENCE OF DdsConfigEntry 479 MAX-ACCESS not-accessible 480 STATUS current 481 DESCRIPTION 482 "The DDS Configuration table contains the basic 483 configuration variables for the CSU/DSU." 484 ::= { ddsObjects 1 } 486 ddsConfigEntry OBJECT-TYPE 487 SYNTAX DdsConfigEntry 488 MAX-ACCESS not-accessible 489 STATUS current 490 DESCRIPTION 491 "An entry in the DDS Configuration table." 492 INDEX { ifIndex } 493 ::= { ddsConfigTable 1 } 495 DdsConfigEntry ::= 496 SEQUENCE { 497 ddsPrimaryChannelSpeed INTEGER, 498 ddsAllowSecondaryChannel TruthValue, 499 ddsAllowNetworkLoops TruthValue, 500 ddsTransmitClockSource INTEGER 501 } 503 ddsPrimaryChannelSpeed OBJECT-TYPE 504 SYNTAX INTEGER { 505 bps2400(1), 506 bps4800(2), 507 bps9600(3), 508 bps19200(4), 509 bps56000(5), 510 bps64000(6) 511 } 512 MAX-ACCESS read-write 513 STATUS current 514 DESCRIPTION 515 "This variable configures the speed of the DDS 516 circuit. This object will actually configure the 517 speed of the line interface circuitry which connects 518 to the DDS line. The line interface circuitry must 519 be programmed to the same rate as that of the DDS 520 circuit that is provided by the carrier." 522 ::= { ddsConfigEntry 1 } 524 ddsAllowSecondaryChannel OBJECT-TYPE 525 SYNTAX TruthValue 526 MAX-ACCESS read-write 527 STATUS current 528 DESCRIPTION 529 "This variable allows or disallows the secondary 530 DDS channel which will run at the following speeds. 532 Primary channel speed Secondary channel speed 533 --------------------- ----------------------- 534 2400 bps 133 bps 535 4800 bps 266 bps 536 9600 bps 533 bps 537 19200 bps 1066 bps 538 56000 bps 2666 bps" 540 ::= { ddsConfigEntry 2 } 542 ddsAllowNetworkLoops OBJECT-TYPE 543 SYNTAX TruthValue 544 MAX-ACCESS read-write 545 STATUS current 546 DESCRIPTION 547 "This variable represents the loopback config- 548 uration of the DDS interface. If it is desired 549 that the CSU/DSU should not respond to latching 550 or non-latching loops from the network, then the 551 variable should be set to the disabled state. If 552 it is desirable to have the CSU/DSU respond to loops 553 from the network, then this variable should be set 554 to enabled." 555 ::= { ddsConfigEntry 3 } 557 ddsTransmitClockSource OBJECT-TYPE 558 SYNTAX INTEGER { 559 loopTiming(1), 560 localTiming(2), 561 throughTiming(3) 562 } 563 MAX-ACCESS read-write 564 STATUS current 565 DESCRIPTION 566 "This variable indicates where the CSU/DSU should 567 derive its timing from. The timing can either 568 come from the internal oscillator (local), the DTE 569 interface (through), or the network interface (loop - 570 the most common option)." 571 ::= { ddsConfigEntry 4 } 573 -- ************************* 574 -- the DDS Diagnostics Table 575 -- ************************* 577 ddsDiagTable OBJECT-TYPE 578 SYNTAX SEQUENCE OF DdsDiagEntry 579 MAX-ACCESS not-accessible 580 STATUS current 581 DESCRIPTION 582 "The DDS diagnostic table contains the diagnostic element 583 variables for the CSU/DSU." 584 ::= { ddsMIB 2 } 586 ddsDiagEntry OBJECT-TYPE 587 SYNTAX DdsDiagEntry 588 MAX-ACCESS not-accessible 589 STATUS current 590 DESCRIPTION 591 "An entry in the DDS diagnostic table." 592 INDEX { ifIndex } 593 ::= { ddsDiagTable 1 } 595 DdsDiagEntry ::= 596 SEQUENCE { 597 ddsLoopbackConfig INTEGER, 598 ddsSendTestCode INTEGER, 599 ddsInsertTestError TruthValue, 600 ddsTestErrorSeconds Counter32, 601 ddsLastTestStart TimeStamp 602 } 604 ddsLoopbackConfig OBJECT-TYPE 605 SYNTAX INTEGER (1..7) 606 MAX-ACCESS read-write 607 STATUS current 608 DESCRIPTION 609 "This object contains the loopback configuration of the 610 network interface of the DSU/CSU. It contains various 611 fields merged together to form a collection of bits in 612 a single variable. The bit-definitions are as follows. 614 1 ddsNoLoop - No loopback activated. 615 2 ddsCSULoop - Activate the CSU loopback. 616 This means that the DDS line 617 should be looped back toward the 618 network. 619 4 ddsLocalLoop - Activate the local network loop. 621 This engages the local loopback 622 of the DSU/CSU which means that 623 the network interface should be 624 looped back toward itself. 625 This is used for self-diagnostic 626 purposes and is not a mode which 627 can be engaged by the TELCO. 629 It should be noted that ddsNoLoop should be the only 630 field set if all loops are to be disabled." 632 ::= { ddsDiagEntry 1 } 634 ddsSendTestCode OBJECT-TYPE 635 SYNTAX INTEGER { 636 sendNoCode(1), 637 sendBERT2047(2), 638 sendAllZeroes(3), 639 sendRemoteLoopCode(4) 640 } 641 MAX-ACCESS read-write 642 STATUS current 643 DESCRIPTION 644 "Activate the bit error-rate tester on the CSU/DSU, 645 which would send the BERT pattern toward the network 646 interface. This object is also used for issuing a 647 remote loopback command to the far-end DDS DSU/CSU." 648 ::= { ddsDiagEntry 2 } 650 ddsInsertTestError OBJECT-TYPE 651 SYNTAX TruthValue 652 MAX-ACCESS read-write 653 STATUS current 654 DESCRIPTION 655 "Inserts a single bit error toward the network 656 interface. This object will only ever read FALSE." 657 ::= { ddsDiagEntry 3 } 659 ddsTestErrorSeconds OBJECT-TYPE 660 SYNTAX Counter32 661 MAX-ACCESS read-only 662 STATUS current 663 DESCRIPTION 664 "The errored-seconds counter. This object reflects 665 the counter which observes the bit-error-rate tester 666 errors being received on the network interface of the 667 DSU/CSU." 668 ::= { ddsDiagEntry 4 } 670 ddsLastTestStart OBJECT-TYPE 671 SYNTAX TimeStamp 672 MAX-ACCESS read-only 673 STATUS current 674 DESCRIPTION 675 "Time stamp for when the BERT test was activated." 676 ::= { ddsDiagEntry 5 } 678 -- ************************ 679 -- the DDS Statistics Table 680 -- ************************ 682 ddsStatisticsTable OBJECT-TYPE 683 SYNTAX SEQUENCE OF DdsStatsEntry 684 MAX-ACCESS not-accessible 685 STATUS current 686 DESCRIPTION 687 "The DDS alarm table contains the statistic counters for 688 the CSU/DSU." 689 ::= { ddsMIB 3 } 691 ddsStatsEntry OBJECT-TYPE 692 SYNTAX DdsStatsEntry 693 MAX-ACCESS not-accessible 694 STATUS current 695 DESCRIPTION 696 "An entry in the DDS statistics table." 697 INDEX { ifIndex } 698 ::= { ddsStatisticsTable 1 } 700 DdsStatsEntry ::= 701 SEQUENCE { 702 ddsLineStatus INTEGER, 703 ddsLOSCount Counter32, 704 ddsOOSCount Counter32, 705 ddsCMICount Counter32, 706 ddsOOFCount Counter32, 707 ddsFERRCount Counter32, 708 ddsBPVCount Counter32 709 } 711 ddsLineStatus OBJECT-TYPE 712 SYNTAX INTEGER (1..1023) 713 MAX-ACCESS read-only 714 STATUS current 715 DESCRIPTION 716 "This object contains the line status of the network 717 interface of the DDS DSU/CSU merged together to form 718 a collection of bits in a single variable. The bit 719 definitions are as follows. 721 1 ddsNoAlarm - No alarm is present. 722 2 ddsLOS - Loss of signal. 723 4 ddsOOS - Out of service. 724 8 ddsCMI - Control mode idle. 725 16 ddsOOF - Out of frame. 726 32 ddsFERR - Frame error. 727 64 ddsBPV - Bipolar violation. 728 128 ddsCSULoop - The CSU loop is active. 729 256 ddsLocalLoop - The local network loop is active. 730 512 ddsOtherLoop - Some other loopback is active. 732 It should be noted that ddsNoAlarm status may only be 733 set when no other alarm or diagnostic condition is 734 present." 736 ::= { ddsStatsEntry 1 } 738 ddsLOSCount OBJECT-TYPE 739 SYNTAX Counter32 740 MAX-ACCESS read-only 741 STATUS current 742 DESCRIPTION 743 "The loss-of-signal errored-second count. This is 744 an error condition that occurs when the line interface 745 has detected that no receive signal is present. This 746 is usually declared after receiving 32 consecutive 747 zeroes on the receive data stream of the network 748 interface." 749 ::= { ddsStatsEntry 2 } 751 ddsOOSCount OBJECT-TYPE 752 SYNTAX Counter32 753 MAX-ACCESS read-only 754 STATUS current 755 DESCRIPTION 756 "The out-of-service errored-second count. This is 757 described in section 9.7.4 of AT&T TR 62310." 758 ::= { ddsStatsEntry 3 } 760 ddsCMICount OBJECT-TYPE 761 SYNTAX Counter32 762 MAX-ACCESS read-only 763 STATUS current 764 DESCRIPTION 765 "The control-mode-idle errored-seconds count. This is 766 described in section 9.7.4 of AT&T TR 62310." 767 ::= { ddsStatsEntry 4 } 769 ddsOOFCount OBJECT-TYPE 770 SYNTAX Counter32 771 MAX-ACCESS read-only 772 STATUS current 773 DESCRIPTION 774 "The out-of-frame errored-seconds count. This is 775 described in section 9.7.4 of AT&T TR 62310." 776 ::= { ddsStatsEntry 5 } 778 ddsFERRCount OBJECT-TYPE 779 SYNTAX Counter32 780 MAX-ACCESS read-only 781 STATUS current 782 DESCRIPTION 783 "The framing-error errored-second count. This condition 784 may only be detected in 64KBPS mode which uses a framing 785 pattern. This errored-second counter is incremented 786 whenever a second is sampled during which a framing 787 error occurred." 788 ::= { ddsStatsEntry 6 } 790 ddsBPVCount OBJECT-TYPE 791 SYNTAX Counter32 792 MAX-ACCESS read-only 793 STATUS current 794 DESCRIPTION 795 "The bipolar-violation errored-seconds count. This 796 counter is incremented whenever a second is sampled 797 during which at least one bipolar violation occurred." 798 ::= { ddsStatsEntry 7 } 800 -- *********************** 801 -- The DDS Interface Group 802 -- *********************** 804 ddsInterfaceGroup OBJECT-GROUP 805 OBJECTS { 806 ddsPrimaryChannelSpeed, 807 ddsAllowSecondaryChannel, 808 ddsAllowNetworkLoops, 809 ddsTransmitClockSource, 810 ddsLoopbackConfig, 811 ddsSendTestCode, 812 ddsInsertTestError, 813 ddsTestErrorSeconds, 814 ddsLastTestStart, 815 ddsLineStatus, 816 ddsLOSCount, 817 ddsOOSCount, 818 ddsCMICount, 819 ddsOOFCount, 820 ddsFERRCount, 821 ddsBPVCount 822 } 824 STATUS current 825 DESCRIPTION 826 "The objects required to instrument a Digital Dataphone 827 System (DDS) Interface." 828 ::= { ddsGroups 1 } 830 -- ************************ 831 -- DDS Interface Compliance 832 -- ************************ 834 ddsInterfaceCompliance MODULE-COMPLIANCE 835 STATUS current 836 DESCRIPTION 837 "The compliance statement for Digital Dataphone System 838 (DDS) interfaces." 839 MODULE -- this module 840 MANDATORY-GROUPS { ddsInterfaceGroup } 841 ::= { ddsCompliances 1} 843 END 845 5. Acknowledgements 847 This document was produced by the Trunk MIB Working Group: 849 Tracy Cox Bellcore 850 Fred Baker Advanced Computer Communications 851 James Watt Newbridge 852 Bill Versteeg Versteeg Codeworks 853 Steve Buchko Newbridge 854 Greg Celmainis Newbridge 855 Kaj Tesink Bellcore 856 Al Bryenton Bell Northern Research 857 Tom Easterday CIC 858 John Labbe Merit Corporation 859 Chris Sullivan Gandalf Ltd 860 Grant Hall Gandalf Ltd 861 Laurence V. Marks IBM Corp. 862 Kurt Hall Clear Communications Corp. 864 Myron Hattig ADC Kentrox 866 Does my name go in here at all? 868 James Watt deserves my thanks for working with me in order to ensure 869 that this memo is compliant with the accepted philosophy of the 870 management framework. 872 I would like to thank Michael Nicolazzo and James Pollock, both 873 of Eastern Research, for supplying their comments and suggestions. 875 6. References 877 [1] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure 878 of Management Information for version 2 of the Simple Network 879 Management Protocol (SNMPv2)", RFC 1442, SNMP Research,Inc., 880 Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon 881 University, April 1993. 883 [2] McCloghrie, K., and M. Rose, Editors, "Management Information 884 Base for Network Management of TCP/IP-based internets: MIB-II", 885 STD 17, RFC 1213, Hughes LAN Systems, Performance Systems 886 International, March 1991. 888 [3] Galvin, J., and K. McCloghrie, "Administrative Model for version 889 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1445, 890 Trusted Information Systems, Hughes LAN Systems, April 1993. 892 [4] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol 893 Operations for version 2 of the Simple Network Management 894 Protocol (SNMPv2)", RFC 1448, SNMP Research,Inc., Hughes LAN 895 Systems, Dover Beach Consulting, Inc., Carnegie Mellon 896 University, April 1993. 898 [5] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple 899 Network Management Protocol", STD 15, RFC 1157, SNMP Research, 900 Performance Systems International, Performance Systems 901 International, MIT Laboratory for Computer Science, May 1990. 903 [6] Information processing systems - Open Systems Interconnection - 904 Specification of Abstract Syntax Notation One (ASN.1), 905 International Organization for Standardization, International 906 Standard 8824, December 1987. 908 [7] Information processing systems - Open Systems Interconnection - 909 Specification of Basic Encoding Rules for Abstract Notation One 910 (ASN.1), International Organization for Standardization, 911 International Standard 8825, December 1987. 913 [8] AT&T Technical Reference, TR 62310, DS0 Digital Local Channel 914 Description and Interface Specification, August 1993. 916 [9] AT&T Technical Reference, TR 62411, ACCUNET T1.5 Service 917 Description And Interface Specification, December 1990. 919 [10] AT&T Technical Reference, TR 62421, ACCUNET Spectrum of 920 Digital Service, December 1989. 922 [11] CCITT Volume VIII, Recommendation V.54, Loop Test Devices for 923 Modems, November 1980. 925 7. Security Considerations 927 Security issues are not discussed in this memo. 929 8. Author's Address 931 Mark A. Cotton 932 Eastern Research, Inc. 933 225 Executive Drive 934 Moorestown, New Jersey 08057 936 Phone: (609)-273-6622 937 EMail: mcotton@erinc.com