Received: from cnri by ietf.org id aa15959; 3 Mar 97 3:05 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa03059; 3 Mar 97 3:05 EST Received: from janus.3com.com (janus.3com.com [129.213.128.99]) by thumper.bellcore.com (8.8.5/8.8.5) with ESMTP id CAA28067 for ; Mon, 3 Mar 1997 02:30:52 -0500 (EST) Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by janus.3com.com (8.8.2/8.8.2) with ESMTP id XAA08154 for ; Sun, 2 Mar 1997 23:30:20 -0800 (PST) Received: from chicago.nsd.3com.com (chicago.nsd.3com.com [129.213.157.11]) by new-york.3com.com (8.8.2/8.8.2) with ESMTP id XAA23314 for ; Sun, 2 Mar 1997 23:24:49 -0800 (PST) Received: from bridge2 (bridge2.NSD.3Com.COM [129.213.96.3]) by chicago.nsd.3com.com (8.8.2/8.8.2) with ESMTP id XAA16151 for ; Sun, 2 Mar 1997 23:29:43 -0800 (PST) Received: from sutter.NSD.3Com.COM (sutter.NSD.3Com.COM [129.213.48.47]) by bridge2 (8.8.2/8.8.2) with SMTP id XAA06032 for ; Sun, 2 Mar 1997 23:30:19 -0800 (PST) Received: by sutter.NSD.3Com.COM id AA23925 (5.65c/IDA-1.4.4-910730 for atommib@thumper.bellcore.com); Sun, 2 Mar 1997 23:29:31 -0800 Date: Sun, 2 Mar 1997 23:29:31 -0800 From: Faye Ly Message-Id: <199703030729.AA23925@sutter.NSD.3Com.COM> To: atommib@thumper.bellcore.com Subject: Re: atmInterface[Conf|Current]MinSvccVci Content-Type: X-sun-attachment ---------- X-Sun-Data-Type: text X-Sun-Data-Description: text X-Sun-Data-Name: text X-Sun-Content-Lines: 0 ---------- X-Sun-Data-Type: default X-Sun-Data-Description: default X-Sun-Data-Name: atmInterface X-Sun-Content-Lines: 26 Hi, Folks, Sorry for the confusion in atmInterfaceExtTable in "draft-ietf-atommib- atm2-08.txt". The correct objects as proposed by Steve B. from NewBridge should be: atmInterfaceConfMaxSvpcVpi INTEGER, atmInterfaceCurrentMaxSvpcVpi INTEGER, atmInterfaceConfMaxSvccVpi INTEGER, atmInterfaceCurrentMaxSvccVpi INTEGER, atmInterfaceConfMinSvccVpci INTEGER, atmInterfaceCurrentMinSvccVpci INTEGER, atmInterfaceConfMinSvccVci INTEGER, atmInterfaceCurrentMinSvccVci INTEGER The current draft missed the last four objects. If there is no more doubts about this. This will be corrected in the next draft. Thanks. -faye   Received: from cnri by ietf.org id aa16528; 3 Mar 97 3:16 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa03219; 3 Mar 97 3:16 EST Received: from janus.3com.com (janus.3com.com [129.213.128.99]) by thumper.bellcore.com (8.8.5/8.8.5) with ESMTP id CAA28190 for ; Mon, 3 Mar 1997 02:43:10 -0500 (EST) Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by janus.3com.com (8.8.2/8.8.2) with ESMTP id XAA08487; Sun, 2 Mar 1997 23:42:39 -0800 (PST) Received: from chicago.nsd.3com.com (chicago.nsd.3com.com [129.213.157.11]) by new-york.3com.com (8.8.2/8.8.2) with ESMTP id XAA23641; Sun, 2 Mar 1997 23:37:08 -0800 (PST) Received: from bridge2 (bridge2.NSD.3Com.COM [129.213.96.3]) by chicago.nsd.3com.com (8.8.2/8.8.2) with ESMTP id XAA16230; Sun, 2 Mar 1997 23:42:01 -0800 (PST) Received: from sutter.NSD.3Com.COM (sutter.NSD.3Com.COM [129.213.48.47]) by bridge2 (8.8.2/8.8.2) with SMTP id XAA06112; Sun, 2 Mar 1997 23:42:37 -0800 (PST) Received: by sutter.NSD.3Com.COM id AA23961 (5.65c/IDA-1.4.4-910730); Sun, 2 Mar 1997 23:41:49 -0800 Date: Sun, 2 Mar 1997 23:41:49 -0800 From: Faye Ly Message-Id: <199703030741.AA23961@sutter.NSD.3Com.COM> To: atommib@thumper.bellcore.com, ssenum@sntc.com Subject: RE: Pos Cc: kaj@cc.bellcore.com Steve Senum said: > Minor point. The draft mentioned contains the following note: > > -- ******** NOTE TO THE RFC EDITOR ************** > -- In case this module is put on the standards track > -- replace the following: > -- "atm2MIB MODULE-IDENTITY ::= {experimental XX}" with > -- "atm2MIB MODULE-IDENTITY ::= {atmMIBObjects 13}" > -- and include atmMIBObjects in the IMPORT clause. > > However, the latest draft of atm1ng contains an object with > the definition: > > atmTrafficDescrParamIndexNext ::= { atmMIBObjects 13} > > Perhaps atm2MIB should be {atmMIBObjects 14}, or maybe > moved to {atmMIB 4}? I thought we agreed Kaj will ask for a new number for the supplemental MIB? {atmMIBObjects 13 or 14} is just a temparary place holder. Kaj, would you please follow up on this. Thanks. -faye   Received: from cnri by ietf.org id aa17447; 3 Mar 97 3:30 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa03372; 3 Mar 97 3:30 EST Received: from janus.3com.com (janus.3com.com [129.213.128.99]) by thumper.bellcore.com (8.8.5/8.8.5) with ESMTP id CAA28410 for ; Mon, 3 Mar 1997 02:59:58 -0500 (EST) Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by janus.3com.com (8.8.2/8.8.2) with ESMTP id XAA08989; Sun, 2 Mar 1997 23:59:28 -0800 (PST) Received: from chicago.nsd.3com.com (chicago.nsd.3com.com [129.213.157.11]) by new-york.3com.com (8.8.2/8.8.2) with ESMTP id XAA24164; Sun, 2 Mar 1997 23:53:56 -0800 (PST) Received: from bridge2 (bridge2.NSD.3Com.COM [129.213.96.3]) by chicago.nsd.3com.com (8.8.2/8.8.2) with ESMTP id XAA16384; Sun, 2 Mar 1997 23:58:50 -0800 (PST) Received: from sutter.NSD.3Com.COM (sutter.NSD.3Com.COM [129.213.48.47]) by bridge2 (8.8.2/8.8.2) with SMTP id XAA06204; Sun, 2 Mar 1997 23:59:26 -0800 (PST) Received: by sutter.NSD.3Com.COM id AA24008 (5.65c/IDA-1.4.4-910730); Sun, 2 Mar 1997 23:58:38 -0800 Date: Sun, 2 Mar 1997 23:58:38 -0800 From: Faye Ly Message-Id: <199703030758.AA24008@sutter.NSD.3Com.COM> To: atommib@thumper.bellcore.com, ajuniper@madge.com Subject: Re: atmInterface[Conf|Current]MinSvccVci Cc: kdu@madge.com, hurmenyi@madge.com, awilliam@madge.com Andy, > > In atm2-08 the atmInterfaceConfMinSvccVci and atmInterfaceCurrentMinSvccVci > objects have been deleted from the atmInterfaceExtTable. > > I can find references in the atommib list archive to changing the Vpi range > limiting from Min to Max, but no reference anywhere to removing these values. > > Was this deliberate? No, it was my mistake. I should add them back into the next draft. > > Also, was there any reason for changing the oid's of the atmVclGenTable and > atmInterfaceExtTable from atmMIBObjects.13.1.12/13 to > atmMIBObjects.13.1.13/14 ? (atmAal5VclStatTable has been inserted at > atmMIBObjects.13.1.12). > Yes, because of the insertion of atmAal5VclStatTable. The OIDs got pushed back by 1 after the atmAal5VclStatTable. I did notice that, I missed this entry in the "Table 1 MIB Structure" before the atmVclGenTable. Again, this shall be fixed in the next draft ... Thanks. -faye   Received: from cnri by ietf.org id aa01755; 3 Mar 97 23:01 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa22302; 3 Mar 97 23:01 EST Received: from bcarsde4.localhost (mailgate.nortel.ca [192.58.194.74]) by thumper.bellcore.com (8.8.5/8.8.5) with ESMTP id WAA29869 for ; Mon, 3 Mar 1997 22:36:18 -0500 (EST) Message-Id: <199703040336.WAA29869@thumper.bellcore.com> Received: from bcarsfba.ott.bnr.ca by bcarsde4.localhost; Mon, 3 Mar 1997 22:26:04 -0500 Received: from bnr.ca by bcarsfba.bnr.ca id <15508-0@bcarsfba.bnr.ca>; Mon, 3 Mar 1997 22:08:36 -0500 Date: 03 Mar 1997 22:08 EST Sender: Richard Vallee To: atommib@thumper.bellcore.com From: Richard Vallee Subject: Question about atmAal5VclTotalErrors I am looking for some clarifications about the following attribute defined under "atmAal5VclStatEntry" in "Definitions of Supplemental Managed Objects for ATM Management": atmAal5VclTotalErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of errored AAL5 CPCS PDUs received on this AAL5 VCL at the interface associated with an AAL5 entity. Total AAL5 errors include invalid CPI and length violation errors in addition to those specific errors listed above" ::= { atmAal5VclStatEntry 1 } => Thus, I have the following questions: 1) Is the "atmAal5VclTotalErrors" object not also including CRC errored frames? 2) If so, is this not already covered by the following attribute under "aal5VccEntry" in "Definitions of Managed Objects for ATM Management"? 3) Should both MIBs, dealing with Aal5VccEntry and atmAal5VclStatEntry, be complementary? aal5VccCrcErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of AAL5 CPCS PDUs received with CRC-32 errors on this AAL5 VCC at the interface associated with an AAL5 entity." ::= { aal5VccEntry 3 } Richard ========================================================== NORTEL Email: vallee@nortel.ca P.O. Box 3511, Station C, Phone: (613) 765-4448 Ottawa, Ontario, Canada, K1Y 4H7 Fax: (613) 763-9406 ==========================================================   Received: from cnri by ietf.org id aa24811; 4 Mar 97 10:34 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa09460; 4 Mar 97 10:34 EST Received: from beast.connix.com (root@beast.connix.com [198.69.10.19]) by thumper.bellcore.com (8.8.5/8.8.5) with ESMTP id JAA11922 for ; Tue, 4 Mar 1997 09:57:36 -0500 (EST) Received: from cy.UUCP (uucp@localhost) by beast.connix.com (8.8.4/8.6.5) with UUCP id JAA06588 for atommib@thumper.bellcore.com; Tue, 4 Mar 1997 09:38:30 -0500 (EST) Received: by cyclone.com (4.1/SMI-4.1) id AA04107; Tue, 4 Mar 97 09:24:55 EST Date: Tue, 4 Mar 97 09:24:55 EST From: Scott Coulter Message-Id: <9703041424.AA04107@cyclone.com> To: atommib@thumper.bellcore.com unsubscribe scoulter@cyclone.com   Received: from cnri by ietf.org id aa14675; 4 Mar 97 19:21 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa22320; 4 Mar 97 19:21 EST Received: from ns.newbridge.com (ns.newbridge.com [192.75.23.67]) by thumper.bellcore.com (8.8.5/8.8.5) with SMTP id SAA01494 for ; Tue, 4 Mar 1997 18:56:36 -0500 (EST) Received: (from smap@localhost) by ns.newbridge.com (8.6.12/8.6.12) id SAA21425; Tue, 4 Mar 1997 18:56:34 -0500 Received: from portero(192.75.23.66) by ns via smap (V1.3) id sma021306; Tue Mar 4 18:55:49 1997 Received: (from smap@localhost) by kanmaster.ca.newbridge.com (8.6.12/8.6.12) id SAA18978; Tue, 4 Mar 1997 18:55:46 -0500 Received: from thor121.ca.newbridge.com(138.120.121.43) by kanmaster.ca.newbridge.com via smap (V1.3) id sma015712; Tue Mar 4 18:22:33 1997 Received: from candy.newbridge (candy [138.120.146.136]) by thor.ca.newbridge.com (8.6.12/8.6.12) with SMTP id SAA11301; Tue, 4 Mar 1997 18:22:31 -0500 From: Steve Buchko Message-Id: <199703042322.SAA11301@thor.ca.newbridge.com> Subject: Re: atmInterface[Conf|Current]MinSvccVci To: Faye Ly Date: Tue, 4 Mar 1997 18:22:28 -0500 (EST) Cc: atommib@thumper.bellcore.com In-Reply-To: <199703030729.AA23925@sutter.NSD.3Com.COM> from "Faye Ly" at Mar 2, 97 11:29:31 pm X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Faye Ly wrote: > Hi, Folks, > > Sorry for the confusion in atmInterfaceExtTable in "draft-ietf-atommib- > atm2-08.txt". The correct objects as proposed by Steve B. from NewBridge > should be: > > atmInterfaceConfMaxSvpcVpi INTEGER, > atmInterfaceCurrentMaxSvpcVpi INTEGER, > atmInterfaceConfMaxSvccVpi INTEGER, > atmInterfaceCurrentMaxSvccVpi INTEGER, > > atmInterfaceConfMinSvccVpci INTEGER, > atmInterfaceCurrentMinSvccVpci INTEGER, > atmInterfaceConfMinSvccVci INTEGER, > atmInterfaceCurrentMinSvccVci INTEGER > > The current draft missed the last four objects. I don't believe there is a need for the VPCI objects, since VPCIs don't appear on the atm interface. The objects I proposed are: atmInterfaceConfMaxSvpcVpi INTEGER, atmInterfaceCurrentMaxSvpcVpi INTEGER, atmInterfaceConfMaxSvccVpi INTEGER, atmInterfaceCurrentMaxSvccVpi INTEGER, atmInterfaceConfMinSvccVci INTEGER, atmInterfaceCurrentMinSvccVci INTEGER The current draft missed the last two objects. Cheers, steve -- Steve Buchko Telephone: (613) 599-3600 ext. 6209 Internet: stevebu@Newbridge.com G3 Fax: (613) 599-3619 "Applying computer technology is simply finding the right wrench to pound in the correct screw." - anonymous   Received: from cnri by ietf.org id aa08474; 6 Mar 97 12:04 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa12827; 6 Mar 97 12:04 EST Received: from tbird.cc.bellcore.com (tbird.cc.bellcore.com [128.96.96.114]) by thumper.bellcore.com (8.8.5/8.8.5) with SMTP id LAA27295 for ; Thu, 6 Mar 1997 11:30:47 -0500 (EST) Received: from joker (joker.bellcore.com) by tbird.cc.bellcore.com with SMTP id AA05969 (5.67b/IDA-1.5 for ); Thu, 6 Mar 1997 11:30:38 -0500 Received: from by joker (4.1/4.7) id AB26990; Thu, 6 Mar 97 11:32:33 EST Date: Thu, 6 Mar 97 11:32:33 EST X-Station-Sent-From: joker.bellcore.com Message-Id: <3.0.16.19970306112957.10ffed58@joker.bellcore.com> X-Sender: kaj@joker.bellcore.com X-Mailer: Windows Eudora Pro Version 3.0 (16) To: atommib@thumper.bellcore.com From: Kaj Tesink Subject: Changes in Cc: kaj@joker.bellcore.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" hi all, here is the list of revisions that were made to the atmtc mib. thanks to all contributors, esp. to mickey! the idea is that this version should be ready for submission to the IESG. so please look it over and holler with any last minute comments. note that mickey's revision of the traffic descriptors was included. in a parallel track we will attempt to get the ILMI synchronized with this list through a procedure using an errata list. kaj ----------------------- the changes are as follows: - changed AtmSignallingType into AtmInterfaceType, included the two new codepoints and used all of mickey's changes. also removed the ATM ILMI from the DESCRIPTION (was between Other and DSS2; must have been some historic text that escaped the delete key) - inserted AtmIlmiNetworkPrefix. - included a sentence clarifying that VPIs can range from 0-4095 in the vp identifier tc. - replaced the traffic descriptors with mickey's list. - some typos   Received: from cnri by ietf.org id aa08607; 6 Mar 97 12:05 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa12854; 6 Mar 97 12:05 EST Received: from tbird.cc.bellcore.com (tbird.cc.bellcore.com [128.96.96.114]) by thumper.bellcore.com (8.8.5/8.8.5) with SMTP id LAA27290 for ; Thu, 6 Mar 1997 11:30:45 -0500 (EST) Received: from joker (joker.bellcore.com) by tbird.cc.bellcore.com with SMTP id AA05965 (5.67b/IDA-1.5 for ); Thu, 6 Mar 1997 11:30:36 -0500 Received: from nv-ktesink.cc.bellcore.com by joker (4.1/4.7) id AA26990; Thu, 6 Mar 97 11:32:28 EST Date: Thu, 6 Mar 97 11:32:28 EST X-Station-Sent-From: joker.bellcore.com Message-Id: <3.0.16.19970306112045.10ffc72c@joker.bellcore.com> X-Sender: kaj@joker.bellcore.com X-Mailer: Windows Eudora Pro Version 3.0 (16) To: Cynthia Clark , atommib@thumper.bellcore.com From: Kaj Tesink Subject: Posting Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_857676656==_" --=====================_857676656==_ Content-Type: text/plain; charset="us-ascii" Hi Cynthia, Can you post the attached as ? Thanks, Kaj --=====================_857676656==_ Content-Type: text/plain; charset="us-ascii" Content-Disposition: attachment; filename="ATMTC.RFC" Definitions of Textual Conventions and OBJECT-IDENTITIES for ATM Management January 8, 1997 Michael Noto (editor) Network Equipment Technologies mike_noto@net.com Ethan Mickey Spiegel (editor) Cisco Systems mspiegel@cisco.com Kaj Tesink (editor) Bell Communications Research kaj@cc.bellcore.com 1. Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as a "work in progress". To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). draft ATM Textual Conventions and OBJECT-IDENTITIES~~~~~~January 8, 1997 2. Introduction This memo describes Textual Conventions and OBJECT-IDENTITIES used for managing ATM-based interfaces, devices, networks and services. When designing a MIB module, it is often useful to define new types similar to those defined in the SMI. In comparison to a type defined in the SMI, each of these new types has a different name, a similar syntax, but a more precise semantics. These newly defined types are termed textual conventions, and are used for the convenience of humans reading the MIB module. This is done through Textual Conventions as defined in RFC1903[1]. It is the purpose of this document to define the set of textual conventions available to ATM MIB modules. When designing MIB modules, it is also often useful to register further properties with object identifier assignments so that they can be further used by other MIB modules. This is done through the OBJECT-IDENTITY macro defined in RFC1902[2]. This document defines OBJECT-IDENTITIES available to ATM MIB modules. Note that for organizational purposes OBJECT IDENTITIES previously defined in RFC1695 have been moved to this specification and no longer appear in the revision of RFC1695[14]. However, the original OBJECT IDENTIFIERs have been preserved. This memo does not specify a standard for the Internet community. Expires 7/8/97 [Page 2] draft ATM Textual Conventions and OBJECT-IDENTITIES~~~~~~January 8, 1997 3. Definitions ATM-TC-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-IDENTITY, Integer32, TimeTicks, mib-2 FROM SNMPv2-SMI TEXTUAL-CONVENTION FROM SNMPv2-TC; atmTCMIB MODULE-IDENTITY LAST-UPDATED "9701080200Z" ORGANIZATION "IETF AToMMIB Working Group" CONTACT-INFO " Michael Noto Postal: Network Equipment Technologies 800 Saginaw Drive RM 21.1.111 Redwood City, CA 94063 USA Tel: +1 415 569-7134 E-mail: mike_noto@net.com Ethan Mickey Spiegel Postal: Cisco Systems 170 W. Tasman Dr. San Jose, CA 95134 USA Tel: +1 408 526 6408 E-mail: mspiegel@cisco.com Kaj Tesink Postal: Bell Communications Research 331 Newman Springs Road Red Bank, NJ 07701 USA Tel: +1 908 758 5254 Fax: +1 908 758 4177 E-mail: kaj@cc.bellcore.com" DESCRIPTION "This MIB Module provides Textuanl Coventions and OBJECT-IDENTITY Objects to be used by ATM systems." ::= { mib-2 37 3 } -- atmMIB 3 Expires 7/8/97 [Page 3] draft ATM Textual Conventions and OBJECT-IDENTITIES~~~~~~January 8, 1997 -- See [14]. -- The Textual Conventions defined below are organized -- alphabetically AtmAddr ::= TEXTUAL-CONVENTION DISPLAY-HINT "1x" STATUS current DESCRIPTION "The ATM address used by the network entity. The address types are: no address (0 octets), E.164 (8 octets), and NSAP (20 octets). Note: The E.164 address is encoded in BCD format." SYNTAX OCTET STRING (SIZE(0|8|20)) AtmConnCastType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The type of topology of a connection (point- to-point, point-to-multipoint). In the case of point-to-multipoint, the orientation of this VPL or VCL in the connection. On a host: - p2mpRoot indicates that the host is the root of the p2mp connection. - p2mpLeaf indicates that the host is a leaf of the p2mp connection. On a switch: - p2mpRoot indicates that cells received by the switching fabric from the interface are from the root of the p2mp connection. - p2mpLeaf indicates that cells transmitted to the interface from the switching fabric are to the leaf of the p2mp connection." SYNTAX INTEGER { p2p(1), p2mpRoot(2), p2mpLeaf(3) } AtmConnKind ::= TEXTUAL-CONVENTION Expires 7/8/97 [Page 4] draft ATM Textual Conventions and OBJECT-IDENTITIES~~~~~~January 8, 1997 STATUS current DESCRIPTION "The use of call control. The use is as follows: pvc(1) Virtual link of a PVC. Should not be used in an PVC/SVC (i.e., SPVC) crossconnect. svcIncoming(2) Virtual link established after a received signaling request to setup an SVC. svcOutgoing(3) Virtual link established after a transmitted or forwarded signaling request to setup an SVC. spvcInitiator(4) Virtual link at the PVC side of an SVC/PVC crossconnect, where the switch is the initiator of the SPVC setup. spvcTarget(5) Virtual link at the PVC side of an SVC/PVC crossconnect, where the switch is the target of the SPVC setup. An spvcInitiator is always cross-connected to an svcOutgoing, and an spvcTarget is always cross-connected to an svcIncoming." SYNTAX INTEGER { pvc(1), svcIncoming(2), svcOutgoing(3), spvcInitiator(4), spvcTarget(5) } AtmIlmiNetworkPrefix ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A network prefix used for ILMI address registration. In the case of ATM endsystem addresses (AESAs), the network prefix is the first 13 octets of the address which includes the AFI, Expires 7/8/97 [Page 5] draft ATM Textual Conventions and OBJECT-IDENTITIES~~~~~~January 8, 1997 IDI, and HO-DSP fields. In the case of native E.164 addresses, the network prefix is the entire E.164 address encoded in 8 octets, as if it were an E.164 IDP in an ATM endsystem address structure." REFERENCE "ATM Forum ILMI 4.0 Section 9, ATM Forum UNI Signalling 4.0 Section 3" SYNTAX OCTET STRING (SIZE(8|13)) AtmInterfaceType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The connection setup procedures used for the identified interface. Other: Connection setup procedures other than those listed below. Auto-configuration: Indicates that the connection setup procedures are to be determined dynamically, or that determination has not yet been completed. One such mechanism is via ATM Forum ILMI auto-configuration procedures. ITU-T DSS2: - ITU-T Recommendation Q.2931, Broadband Integrated Service Digital Network (B-ISDN) Digital Subscriber Signalling System No.2 (DSS2) User-Network Interface (UNI) Layer 3 Specification for Basic Call/Connection Control (September 1994) [5] - ITU-T Draft Recommendation Q.2961, B-ISDN DSS 2 Support of Additional Traffic Parameters (May 1995) [8] - ITU-T Draft Recommendation Q.2971, B-ISDN DSS 2 User Network Interface Layer 3 Specification for Point-to-multipoint Call/connection Control (May 1995) [9] ATM Forum UNI 3.0: ATM Forum, ATM User-Network Interface, Version 3.0 (UNI 3.0) Specification, Expires 7/8/97 [Page 6] draft ATM Textual Conventions and OBJECT-IDENTITIES~~~~~~January 8, 1997 (1994) [3]. ATM Forum UNI 3.1: ATM Forum, ATM User-Network Interface, Version 3.1 (UNI 3.1) Specification, (November 1994) [4]. ATM Forum UNI Signalling 4.0: ATM Forum, ATM User-Network Interface (UNI) Signalling Specification Version 4.0, af-sig-0061.000 (June 1996) [7]. ATM Forum IISP (based on UNI 3.0 or UNI 3.1) : Interim Inter-switch Signaling Protocol (IISP) Specification, Version 1.0, af-pnni-0026.000, (December 1994) [10]. ATM Forum PNNI 1.0 : ATM Forum, Private Network-Network Interface Specification, Version 1.0, af-pnni-0055.000, (March 1996) [6]. ATM Forum B-ICI: ATM Forum, B-ICI Specification, Version 2.0, af-bici-0013.002, (November 1995) [11]. ATM Forum UNI PVC Only: An ATM Forum compliant UNI with the signalling disabled. ATM Forum NNI PVC Only: An ATM Forum compliant NNI with the signalling disabled." SYNTAX INTEGER { other(1), autoConfig(2), ituDss2(3), atmfUni3Dot0(4), atmfUni3Dot1(5), atmfUni4Dot0(6), atmfIispUni3Dot0(7), atmfIispUni3Dot1(8), atmfIispUni4Dot0(9), atmfPnni1Dot0(10), atmfBici2Dot0(11), Expires 7/8/97 [Page 7] draft ATM Textual Conventions and OBJECT-IDENTITIES~~~~~~January 8, 1997 atmfUniPvcOnly(12), atmfNniPvcOnly(13) } AtmServiceCategory ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The service category for a connection." REFERENCE "ATM Forum Traffic Management 4.0." SYNTAX INTEGER { other(1), -- none of the following cbr(2), -- constant bit rate rtVbr(3), -- real-time variable bit rate nrtVbr(4), -- non real-time variable bit rate abr(5), -- available bit rate ubr(6) -- unspecified bit rate } AtmSigDescrParamIndex ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The value of this object identifies a row in the atmSigDescrParamTable. The value 0 signifies that none of the signalling parameters defined in the atmSigDescrParamTable are applicable." SYNTAX Integer32 AtmTrafficDescrParamIndex ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The value of this object identifies a row in the atmTrafficDescrParamTable. The value 0 signifies that no row has been identified." SYNTAX INTEGER (0..4294967295) AtmVcIdentifier ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The VCI value for a VCL. The maximum VCI value cannot exceed the value allowable by atmInterfaceMaxVciBits defined in ATM-MIB." SYNTAX INTEGER (0..65535) AtmVpIdentifier ::= TEXTUAL-CONVENTION STATUS current Expires 7/8/97 [Page 8] draft ATM Textual Conventions and OBJECT-IDENTITIES~~~~~~January 8, 1997 DESCRIPTION "The VPI value for a VPL or VCL. The value VPI=0 is only allowed for a VCL. For ATM UNIs supporting VPCs the VPI value ranges from 1 to 255. For ATM UNIs supporting VCCs the VPI value ranges from 0 to 255. For ATM NNIs the VPI value ranges from 0 to 4095. The maximum VPI value cannot exceed the value allowable by atmInterfaceMaxVpiBits defined in ATM-MIB." SYNTAX INTEGER (0..4095) AtmVorXAdminStatus ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The value determines the desired administrative status of a virtual link or cross-connect. The up and down states indicate that the traffic flow is enabled or disabled respectively on the virtual link or cross-connect." SYNTAX INTEGER { up(1), down(2) } AtmVorXLastChange ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The value of MIB II's sysUpTime at the time this virtual link or cross-connect entered its current operational state. If the current state was entered prior to the last re-initialization of the agent then this object contains a zero value." SYNTAX TimeTicks AtmVorXOperStatus ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The value determines the operational status of a virtual link or cross-connect. The up and down states indicate that the traffic flow is enabled or disabled respectively on the virtual link or cross-connect. The unknown state indicates that the state of it cannot be determined. The state will be down or unknown if the supporting ATM interface(s) is down or unknown respectively." Expires 7/8/97 [Page 9] draft ATM Textual Conventions and OBJECT-IDENTITIES~~~~~~January 8, 1997 SYNTAX INTEGER { up(1), down(2), unknown(3) } -- OBJECT-IDENTITIES: -- The following atmTrafficDescriptorTypes has been moved -- from [14]. atmTrafficDescriptorTypes OBJECT IDENTIFIER ::= {mib-2 37 1 1} -- atmMIBObjects -- See [14]. -- All other and new OBJECT IDENTITIES go here: atmObjectIdentities OBJECT IDENTIFIER ::= {atmTCMIB 1} -- The following values are defined for use as -- possible values of the ATM traffic descriptor type. atmNoTrafficDescriptor OBJECT-IDENTITY STATUS deprecated DESCRIPTION "This identifies the no ATM traffic descriptor type. Parameters 1, 2, 3, 4, and 5 are not used. This traffic descriptor type can be used for best effort traffic." ::= {atmTrafficDescriptorTypes 1} atmNoClpNoScr OBJECT-IDENTITY STATUS current DESCRIPTION "This traffic descriptor type is for no CLP and no Sustained Cell Rate. The use of the parameter vector for this type: Parameter 1: peak cell rate in cells/second for CLP=0+1 traffic Parameter 2: CDVT in tenths of microseconds Parameter 3: not used Parameter 4: not used Expires 7/8/97 [Page 10] draft ATM Textual Conventions and OBJECT-IDENTITIES~~~~~~January 8, 1997 Parameter 5: not used. This traffic descriptor type is applicable to CBR connections following the UNI 3.0/3.1 conformance definition for PCR CLP=0+1 [3,4]. These CBR connections differ from CBR.1 connections [13] in that the CLR objective applies only to the CLP=0 cell flow. This traffic descriptor type is also applicable to connections following the UBR.1 conformance definition [13]." ::= {atmTrafficDescriptorTypes 2} atmClpNoTaggingNoScr OBJECT-IDENTITY STATUS deprecated DESCRIPTION "This traffic descriptor is for CLP without tagging and no Sustained Cell Rate. The use of the parameter vector for this type: Parameter 1: peak cell rate in cells/second for CLP=0+1 traffic Parameter 2: peak cell rate in cells/second for CLP=0 traffic Parameter 3: not used Parameter 4: not used Parameter 5: not used." ::= {atmTrafficDescriptorTypes 3} atmClpTaggingNoScr OBJECT-IDENTITY STATUS deprecated DESCRIPTION "This traffic descriptor is for CLP with tagging and no Sustained Cell Rate. The use of the parameter vector for this type: Parameter 1: peak cell rate in cells/second for CLP=0+1 traffic Parameter 2: peak cell rate in cells/second for CLP=0 traffic, excess tagged as CLP=1 Parameter 3: not used Parameter 4: not used Parameter 5: not used." ::= {atmTrafficDescriptorTypes 4} Expires 7/8/97 [Page 11] draft ATM Textual Conventions and OBJECT-IDENTITIES~~~~~~January 8, 1997 atmNoClpScr OBJECT-IDENTITY STATUS current DESCRIPTION "This traffic descriptor type is for no CLP with Sustained Cell Rate. The use of the parameter vector for this type: Parameter 1: peak cell rate in cells/second for CLP=0+1 traffic Parameter 2: sustainable cell rate in cells/second for CLP=0+1 traffic Parameter 3: maximum burst size in cells Parameter 4: CDVT in tenths of microseconds Parameter 5: not used. This traffic descriptor type is applicable to VBR connections following the UNI 3.0/3.1 conformance definition for PCR CLP=0+1 and SCR CLP=0+1 [3,4]. These VBR connections differ from VBR.1 connections [13] in that the CLR objective applies only to the CLP=0 cell flow." ::= {atmTrafficDescriptorTypes 5} atmClpNoTaggingScr OBJECT-IDENTITY STATUS current DESCRIPTION "This traffic descriptor type is for CLP with Sustained Cell Rate and no tagging. The use of the parameter vector for this type: Parameter 1: peak cell rate in cells/second for CLP=0+1 traffic Parameter 2: sustainable cell rate in cells/second for CLP=0 traffic Parameter 3: maximum burst size in cells Parameter 4: CDVT in tenths of microseconds Parameter 5: not used. This traffic descriptor type is applicable to connections following the VBR.2 conformance definition [13]." ::= {atmTrafficDescriptorTypes 6} atmClpTaggingScr OBJECT-IDENTITY STATUS current DESCRIPTION Expires 7/8/97 [Page 12] draft ATM Textual Conventions and OBJECT-IDENTITIES~~~~~~January 8, 1997 "This traffic descriptor type is for CLP with tagging and Sustained Cell Rate. The use of the parameter vector for this type: Parameter 1: peak cell rate in cells/second for CLP=0+1 traffic Parameter 2: sustainable cell rate in cells/second for CLP=0 traffic, excess tagged as CLP=1 Parameter 3: maximum burst size in cells Parameter 4: CDVT in tenths of microseconds Parameter 5: not used. This traffic descriptor type is applicable to connections following the VBR.3 conformance definition [13]." ::= {atmTrafficDescriptorTypes 7} atmClpNoTaggingMcr OBJECT-IDENTITY STATUS current DESCRIPTION "This traffic descriptor type is for CLP with Minimum Cell Rate and no tagging. The use of the parameter vector for this type: Parameter 1: peak cell rate in cells/second for CLP=0+1 traffic Parameter 2: CDVT in tenths of microseconds Parameter 3: minimum cell rate in cells/second Parameter 4: unused Parameter 5: unused. This traffic descriptor type is applicable to connections following the ABR conformance definition [13]." ::= {atmTrafficDescriptorTypes 8} atmClpTransparentNoScr OBJECT-IDENTITY STATUS current DESCRIPTION "This traffic descriptor type is for the CLP- transparent model [13] and no Sustained Cell Rate. The use of the parameter vector for this type: Parameter 1: peak cell rate in cells/second for CLP=0+1 traffic Parameter 2: CDVT in tenths of microseconds Parameter 3: not used Expires 7/8/97 [Page 13] draft ATM Textual Conventions and OBJECT-IDENTITIES~~~~~~January 8, 1997 Parameter 4: not used Parameter 5: not used. This traffic descriptor type is applicable to connections following the CBR.1 conformance definition [13]. Connections specifying this traffic descriptor type will be rejected at UNI 3.0 or UNI 3.1 interfaces. For a similar traffic descriptor type that can be accepted at UNI 3.0 and UNI 3.1 interfaces, see atmNoClpNoScr." ::= {atmTrafficDescriptorTypes 9} atmClpTransparentScr OBJECT-IDENTITY STATUS current DESCRIPTION "This traffic descriptor type is for the CLP- transparent model [13] with Sustained Cell Rate. The use of the parameter vector for this type: Parameter 1: peak cell rate in cells/second for CLP=0+1 traffic Parameter 2: sustainable cell rate in cells/second for CLP=0+1 traffic Parameter 3: maximum burst size in cells Parameter 4: CDVT in tenths of microseconds Parameter 5: not used. This traffic descriptor type is applicable to connections following the VBR.1 conformance definition [13]. Connections specifying this traffic descriptor type will be rejected at UNI 3.0 or UNI 3.1 interfaces. For a similar traffic descriptor type that can be accepted at UNI 3.0 and UNI 3.1 interfaces, see atmNoClpScr." ::= {atmTrafficDescriptorTypes 10} atmNoClpTaggingNoScr OBJECT-IDENTITY STATUS current DESCRIPTION "This traffic descriptor type is for no CLP with tagging and no Sustained Cell Rate. The use of the parameter vector for this type: Expires 7/8/97 [Page 14] draft ATM Textual Conventions and OBJECT-IDENTITIES~~~~~~January 8, 1997 Parameter 1: peak cell rate in cells/second for CLP=0+1 traffic Parameter 2: CDVT in tenths of microseconds Parameter 3: not used Parameter 4: not used Parameter 5: not used. This traffic descriptor type is applicable to connections following the UBR.2 conformance definition [13]." ::= {atmTrafficDescriptorTypes 11} END Expires 7/8/97 [Page 15] draft ATM Textual Conventions and OBJECT-IDENTITIES~~~~~~January 8, 1997 4. Acknowledgments This document is a product of the AToMMIB Working Group. Expires 7/8/97 [Page 16] draft ATM Textual Conventions and OBJECT-IDENTITIES~~~~~~January 8, 1997 5. References [1] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Textual Conventions for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC1903, SNMP Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [2] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC1902, SNMP Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [3] ATM Forum, "ATM User-Network Interface, Version 3.0 (UNI 3.0) Specification", 1994. [4] ATM Forum, "ATM User-Network Interface, Version 3.1 (UNI 3.1) Specification", November 1994. [5] ITU-T Recommendation Q.2931, "Broadband Integrated Service Digital Network (B-ISDN) Digital Subscriber Signalling System No.2 (DSS2) User-Network Interface (UNI) Layer 3 Specification for Basic Call/Connection Control", September 1994. [6] ATM Forum, "Private Network-Network Interface Specification Version 1.0 (P-NNI 1.0)", af-pnni-0055.000, March 1996. [7] ATM Forum, "ATM User-Network Interface Signalling Specification, Version 4.0 (UNI 4.0)", af-sig-0061.000, June 1996. [8] ITU-T Draft Recommendation Q.2961, "Broadband Integrated Service Digital Network (B-ISDN) Digital Subscriber Signalling System No.2 (DSS2) Support of Additional Traffic Parameters", May 1995. [9] ITU-T Draft Recommendation Q.2971, "Broadband Integrated Service Digital Network (B-ISDN) Digital Subscriber Signalling System No.2 (DSS2) User Network Interface Layer 3 Specification for Point-to-multipoint Expires 7/8/97 [Page 17] draft ATM Textual Conventions and OBJECT-IDENTITIES~~~~~~January 8, 1997 Call/connection Control", May 1995. [10] ATM Forum, "Interim Inter-switch Signaling Protocol (IISP)Specification, Version 1.0", af-pnni-0026.000, December 1994. [11] ATM Forum, "B-ICI Specification, Version 2.0", af-bici- 0013.002, November 1995. [12] ATM Forum, "Integrated Local Management Interface Specification, Version 4.0", af-ilmi-0065.000, July 1996. [13] ATM Forum, "Traffic Management Specification, Version 4.0", af-tm-0056.000, June 1996. [14] Kaj Tesink, "Definitions of Managed Objects for ATM Management", RFC???? (Internet-Draft ), Bellcore, October 1996. Expires 7/8/97 [Page 18] draft ATM Textual Conventions and OBJECT-IDENTITIES~~~~~~January 8, 1997 6. Security Considerations Security issues are not discussed in this memo. 7. Authors' Addresses Michael Noto Network Equipment Technologies 800 Saginaw Drive RM 21.1.111 Redwood City, CA 94063 Phone +1 415 569-7134 EMail: mike_noto@net.com Ethan Mickey Spiegel Cisco Systems 170 W. Tasman Dr. San Jose, CA 95134 USA Phone +1 408 526 6408 E-mail: mspiegel@cisco.com" Kaj Tesink Bell Communications Research Room 1A-317 331 Newman Springs Road P.O. Box 7020 Red Bank, NJ 07701-7020 Phone: (908) 758-5254 EMail: kaj@cc.bellcore.com Expires 7/8/97 [Page 19] draft ATM Textual Conventions and OBJECT-IDENTITIES~~~~~~January 8, 1997 Table of Contents 1 Status of this Memo ................................... 1 2 Introduction .......................................... 2 3 Definitions ........................................... 3 4 Acknowledgments ....................................... 16 5 References ............................................ 17 6 Security Considerations ............................... 19 7 Authors' Addresses .................................... 19 Expires 7/8/97 [Page 20] --=====================_857676656==_ Content-Type: text/plain; charset="us-ascii" _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ _/ _/ _/ Kaj Tesink _/ _/ Bellcore _/ _/ - Emerging Networks vmail (908) 758-5254 _/ _/ 331 Newman Springs Rd. email kaj@cc.bellcore.com _/ _/ Red Bank, NJ 07701 faxmail (908) 758-4177 _/ _/ _/ _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ --=====================_857676656==_--   Received: from cnri by ietf.org id aa01766; 7 Mar 97 10:16 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa09132; 7 Mar 97 10:16 EST Received: from ietf.org (ietf.org [132.151.1.19]) by thumper.bellcore.com (8.8.5/8.8.5) with SMTP id JAA00936 for ; Fri, 7 Mar 1997 09:38:55 -0500 (EST) Received: from ietf.ietf.org by ietf.org id aa28074; 7 Mar 97 9:37 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: atommib@thumper.bellcore.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-atommib-atm2TC-06.txt Date: Fri, 07 Mar 1997 09:37:55 -0500 Sender: cclark@ietf.org Message-ID: <9703070937.aa28074@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the AToM MIB Working Group of the IETF. Title : Definitions of Textual Conventions and OBJECT-IDENTITIES for ATM Management Author(s) : M. Noto, E. Spiegel, K. Tesink Filename : draft-ietf-atommib-atm2TC-06.txt Pages : 20 Date : 03/06/1997 This memo describes Textual Conventions and OBJECT-IDENTITIES used for managing ATM-based interfaces, devices, networks and services. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-atommib-atm2TC-06.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-atommib-atm2TC-06.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: ftp.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-atommib-atm2TC-06.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970306135419.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-atommib-atm2TC-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-atommib-atm2TC-06.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970306135419.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from cnri by ietf.org id aa12189; 7 Mar 97 13:00 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa12861; 7 Mar 97 13:00 EST Received: from janus.3com.com (janus.3com.com [129.213.128.99]) by thumper.bellcore.com (8.8.5/8.8.5) with ESMTP id MAA07186 for ; Fri, 7 Mar 1997 12:20:06 -0500 (EST) Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by janus.3com.com (8.8.2/8.8.2) with ESMTP id JAA03158; Fri, 7 Mar 1997 09:19:27 -0800 (PST) Received: from chicago.nsd.3com.com (chicago.nsd.3com.com [129.213.157.11]) by new-york.3com.com (8.8.2/8.8.2) with ESMTP id JAA05533; Fri, 7 Mar 1997 09:13:11 -0800 (PST) Received: from bridge2 (bridge2.NSD.3Com.COM [129.213.96.3]) by chicago.nsd.3com.com (8.8.2/8.8.2) with ESMTP id JAA27470; Fri, 7 Mar 1997 09:18:45 -0800 (PST) Received: from sutter.NSD.3Com.COM (sutter.NSD.3Com.COM [129.213.48.47]) by bridge2 (8.8.2/8.8.2) with SMTP id JAA22008; Fri, 7 Mar 1997 09:19:26 -0800 (PST) Received: by sutter.NSD.3Com.COM id AA05596 (5.65c/IDA-1.4.4-910730); Fri, 7 Mar 1997 09:18:20 -0800 Date: Fri, 7 Mar 1997 09:18:20 -0800 From: Faye Ly Message-Id: <199703071718.AA05596@sutter.NSD.3Com.COM> To: fayely@3com.com, stevebu@ca.newbridge.com Subject: Re: atmInterface[Conf|Current]MinSvccVci Cc: atommib@thumper.bellcore.com Steve, Thank you for the correction. This shall be done in the next draft. -faye > From stevebu@ca.newbridge.com Tue Mar 4 15:55:43 1997 > From: Steve Buchko > Subject: Re: atmInterface[Conf|Current]MinSvccVci > To: fayely@3com.com (Faye Ly) > Date: Tue, 4 Mar 1997 18:22:28 -0500 (EST) > Cc: atommib@thumper.bellcore.com > In-Reply-To: <199703030729.AA23925@sutter.NSD.3Com.COM> from "Faye Ly" at Mar 2, 97 11:29:31 pm > X-Mailer: ELM [version 2.4 PL22] > Mime-Version: 1.0 > Content-Type> : > text/plain> ; > charset=US-ASCII> > Content-Transfer-Encoding: 7bit > Content-Length: 1578 > X-Lines: 42 > > Faye Ly wrote: > > Hi, Folks, > > > > Sorry for the confusion in atmInterfaceExtTable in "draft-ietf-atommib- > > atm2-08.txt". The correct objects as proposed by Steve B. from NewBridge > > should be: > > > > atmInterfaceConfMaxSvpcVpi INTEGER, > > atmInterfaceCurrentMaxSvpcVpi INTEGER, > > atmInterfaceConfMaxSvccVpi INTEGER, > > atmInterfaceCurrentMaxSvccVpi INTEGER, > > > > atmInterfaceConfMinSvccVpci INTEGER, > > atmInterfaceCurrentMinSvccVpci INTEGER, > > atmInterfaceConfMinSvccVci INTEGER, > > atmInterfaceCurrentMinSvccVci INTEGER > > > > The current draft missed the last four objects. > > I don't believe there is a need for the VPCI objects, since VPCIs > don't appear on the atm interface. The objects I proposed are: > > atmInterfaceConfMaxSvpcVpi INTEGER, > atmInterfaceCurrentMaxSvpcVpi INTEGER, > atmInterfaceConfMaxSvccVpi INTEGER, > atmInterfaceCurrentMaxSvccVpi INTEGER, > > atmInterfaceConfMinSvccVci INTEGER, > atmInterfaceCurrentMinSvccVci INTEGER > > The current draft missed the last two objects. > > Cheers, > steve > > -- > Steve Buchko Telephone: (613) 599-3600 ext. 6209 > Internet: stevebu@Newbridge.com G3 Fax: (613) 599-3619 > > "Applying computer technology is simply finding the right > wrench to pound in the correct screw." > - anonymous >   Received: from cnri by ietf.org id aa20755; 10 Mar 97 15:56 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa15688; 10 Mar 97 15:56 EST Received: from cbgw3.lucent.com (cbgw3.lucent.com [192.20.239.137]) by thumper.bellcore.com (8.8.5/8.8.5) with SMTP id PAA18384 for ; Mon, 10 Mar 1997 15:24:58 -0500 (EST) From: dxie@mtgbcs.mt.lucent.com To: ajit@mtgbcs.mt.lucent.com, anh@mtgbcs.mt.lucent.com, atommib@thumper.bellcore.com, flu@mtgbcs.mt.lucent.com, gjs@mtgbcs.mt.lucent.com, hill@mtgbcs.mt.lucent.com, dxie@mtgbcs.mt.lucent.com Received: from mtgbcs.mt.lucent.com by cbig3.firewall.lucent.com (SMI-8.6/EMS-L sol2) id PAA06917; Mon, 10 Mar 1997 15:15:35 -0500 Received: from mtpcs52-102 by mtgbcs.mt.lucent.com (5.0/EMS-L sol2) id AA22550; Mon, 10 Mar 1997 15:25:26 -0500 Message-Id: <970310153015.ZM2887@mtpcs52-102> Date: Mon, 10 Mar 1997 15:30:10 -0400 In-Reply-To: Kaj Tesink " Posting" (Mar 6, 11:32am) References: <3.0.16.19970306112045.10ffc72c@joker.bellcore.com> X-Mailer: Z-Mail 4.0 (4.0.0 Aug 21 1995) Original-To: ajit@mtgbcs.mt.lucent.com, anh@mtgbcs.mt.lucent.com, atommib@thumper.bellcore.com, flu@mtgbcs.mt.lucent.com, gjs@mtgbcs.mt.lucent.com, hill@mtgbcs.mt.lucent.com, dxie@mtgbcs.mt.lucent.com Subject: atmfMySystemIdentifier Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In ATM Forum ILMI MIB, atmfMySystemIdentifier object can be exchanged between the IME peers. The value of the object can uniquely identify the system in the MAC address space. However, do anybody know whether this object is reflected in any IETF MIB definitions? And should a device implement this object? We can already identify a device using its IP address, or ATM NSAP address. Why we need to assign another identifier to a device? Thanks for any help. -- Dawn Xie dawnxie@lucent.com (908) 957-2066   Received: from cnri by ietf.org id aa29357; 11 Mar 97 9:04 EST Received: from inet2.tek.com by CNRI.Reston.VA.US id aa07858; 11 Mar 97 9:04 EST Received: from bocote.vndad.tek.com by inet2.tek.com id ; Tue, 11 Mar 1997 05:47:55 -0800 Received: (from daemon@localhost) by bocote.vndad.tek.com (8.7.5/8.7.3) id FAA27665 for if-mib-outgoing; Tue, 11 Mar 1997 05:47:53 -0800 (PST) Received: from tektronix.tek.com (tektronix.tek.com [134.62.8.103]) by bocote.vndad.tek.com (8.7.5/8.7.3) with ESMTP id FAA27659 for ; Tue, 11 Mar 1997 05:47:49 -0800 (PST) Received: from inet2.tek.com (inet2-en1.tek.com [134.62.8.58]) by tektronix.tek.com (8.7.5/8.7.3) with SMTP id FAA12707 for ; Tue, 11 Mar 1997 05:47:46 -0800 (PST) Received: from tbird.cc.bellcore.com by inet2.tek.com id ; Tue, 11 Mar 1997 05:47:43 -0800 Received: from joker (joker.bellcore.com) by tbird.cc.bellcore.com with SMTP id AA06597 (5.67b/IDA-1.5 for ); Tue, 11 Mar 1997 08:47:32 -0500 Received: from nv-ktesink.cc.bellcore.com by joker (4.1/4.7) id AA25542; Tue, 11 Mar 97 08:49:29 EST Date: Tue, 11 Mar 97 08:49:29 EST X-Station-Sent-From: joker.bellcore.com Message-Id: <3.0.16.19970311084755.4927c77e@joker.bellcore.com> X-Sender: kaj@joker.bellcore.com X-Mailer: Windows Eudora Pro Version 3.0 (16) To: atommib@thumper.bellcore.com, if-mib From: Kaj Tesink Subject: test mib, atm test mib Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: if-mib-owner@vndad.tek.com Precedence: bulk hi, a small band of people (dawn, chris, james and the authors) got together to discuss implementation feedback of the proposed test mib and the atm test mib that uses it. the consensus was that based on this implementation experience the current test mib structure can be simplified. specifically: - after all a read-create test table turned out to be easier to implement than the current structure - the two tables can then also be collapsed into a single table - a test capabilities table may be a useful addition these changes would not affect the atm test mib much although some minor adjustments may have to be made. if nobody objects we'll prepare a revision of the i-ds with these simplifications. kaj _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ _/ _/ _/ Kaj Tesink _/ _/ Bellcore _/ _/ - Emerging Networks vmail (908) 758-5254 _/ _/ 331 Newman Springs Rd. email kaj@cc.bellcore.com _/ _/ Red Bank, NJ 07701 faxmail (908) 758-4177 _/ _/ _/ _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/   Received: from cnri by ietf.org id aa08500; 11 Mar 97 12:19 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa12461; 11 Mar 97 12:19 EST Received: from inet2.tek.com (inet2.tek.com [134.62.48.22]) by thumper.bellcore.com (8.8.5/8.8.5) with SMTP id LAA16523 for ; Tue, 11 Mar 1997 11:53:22 -0500 (EST) Received: from icebox.vnd.tek.com by inet2.tek.com id ; Tue, 11 Mar 1997 08:52:50 -0800 Received: from icebox (localhost [127.0.0.1]) by icebox.vnd.tek.com (8.7.5/8.7.3) with ESMTP id JAA00164; Tue, 11 Mar 1997 09:00:09 -0800 (PST) Message-Id: <199703111700.JAA00164@icebox.vnd.tek.com> To: Kaj Tesink Cc: atommib@thumper.bellcore.com, if-mib From: "Ted Brunner 503.627.1317" Subject: Re: test mib, atm test mib In-reply-to: Your message of Tue, 11 Mar 1997 08:49:29 -0500. <3.0.16.19970311084755.4927c77e@joker.bellcore.com> Date: Tue, 11 Mar 1997 09:00:09 -0800 Sender: tedb@vnd.tek.com I think you should make the appropriate changes, since it your group which understands the desired functionality best. > a small band of people (dawn, chris, james and the authors) got together > to discuss implementation feedback of the proposed test mib and > the atm test mib that uses it. the consensus was > that based on this implementation experience the current > test mib structure can be simplified. specifically: > > - after all a read-create test table turned out to be easier to implement > than the current structure > > - the two tables can then also be collapsed into a single table > > - a test capabilities table may be a useful addition > > these changes would not affect the atm test mib much although > some minor adjustments may have to be made. > > if nobody objects we'll prepare a revision of the i-ds with these simplifications. Ted Brunner Video and Networking Division Tektronix MS 50-490 ted.brunner@tek.com 14150 SW Karl Braun 503.627.1317 Beaverton OR 97005   Received: from cnri by ietf.org id aa04453; 17 Mar 97 23:18 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa00452; 17 Mar 97 23:18 EST Received: from tbird.cc.bellcore.com (tbird.cc.bellcore.com [128.96.96.114]) by thumper.bellcore.com (8.8.5/8.8.5) with SMTP id WAA24853 for ; Mon, 17 Mar 1997 22:47:45 -0500 (EST) Received: from joker (joker.bellcore.com) by tbird.cc.bellcore.com with SMTP id AA03475 (5.67b/IDA-1.5 for ); Mon, 17 Mar 1997 22:47:32 -0500 Received: from @joker.bellcore.com (nvc-slip4.cc.bellcore.com) by joker (4.1/4.7) id AA15578; Mon, 17 Mar 97 22:49:31 EST X-Station-Sent-From: joker.bellcore.com Message-Id: <3.0.16.19970317223913.2aff90ac@joker.bellcore.com> X-Sender: kaj@joker.bellcore.com (Unverified) X-Mailer: Windows Eudora Pro Version 3.0 (16) Date: Mon, 17 Mar 1997 22:40:18 -0500 To: atommib@thumper.bellcore.com From: Kaj Tesink Subject: SONET/SDH Suppl MIB Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" hi, i have still an action item to clone the suppl ds1/ds3 mibs for sonet/sdh. since these suppl mibs seem to differ somewhat i want to make sure i have the functional requirements right. what about this list: suppl sonet/sdh mib functions: - thresholding - day interval counters - reset capability anything else? kaj _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ _/ _/ _/ Kaj Tesink _/ _/ Bellcore _/ _/ - Broadband Data Services & Consulting vmail (908) 758-5254 _/ _/ 331 Newman Springs Rd. email kaj@cc.bellcore.com _/ _/ Red Bank, NJ 07701 faxmail (908) 758-4177 _/ _/ _/ _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/   Received: from cnri by ietf.org id aa12006; 18 Mar 97 2:09 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa03310; 18 Mar 97 2:09 EST Received: from one-o.com (canaan.one-o.com [206.151.128.11]) by thumper.bellcore.com (8.8.5/8.8.5) with SMTP id BAA27504 for ; Tue, 18 Mar 1997 01:47:34 -0500 (EST) Received: from jericho.one-o.com (jericho [206.151.128.12]) by one-o.com (SMI-8.6/SMI-SVR4-OOI951120) id WAA25675; Mon, 17 Mar 1997 22:47:32 -0800 Received: (from heard@localhost) by jericho.one-o.com (SMI-8.6/SMI-SVR4) id WAA21880; Mon, 17 Mar 1997 22:47:32 -0800 Date: Mon, 17 Mar 1997 22:47:32 -0800 Message-Id: <199703180647.WAA21880@jericho.one-o.com> To: atommib@thumper.bellcore.com Subject: Re: SONET/SDH Suppl MIB From: "C. M. Heard/VVNET, Inc." In-Reply-To: <3.0.16.19970317223913.2aff90ac@joker.bellcore.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" On Mon, 17 Mar 1997 Kaj Tesink wrote: > i have still an action item to clone the suppl ds1/ds3 mibs > for sonet/sdh. since these suppl mibs seem to differ somewhat > i want to make sure i have the functional requirements right. Kaj, This got my attention, since I don't follow the trunkmib list and was not aware of the suppl ds1/ds3 mibs. Looks like I have some reading to catch up on. Looking in the I-D directory on ds.internic.net I found what I thought might be a draft of the suppl ds1 mib -- draft-ietf-trunkmib-ds1-supp-00.txt -- but it turns out that this is just a note to the effect that the draft has expired and has been deleted. Can you tell me where to find the current (draft or published) suppl ds1/ds3 mibs, so I can look at what it is that needs to be cloned? > what about this list: > > suppl sonet/sdh mib functions: > - thresholding > - day interval counters > - reset capability > > anything else? You might want to consider adding failure counts. These are present in T1.231-1993 but are absent from the SONET mib. Also, please be aware that an ANSI T1M1.3 working group is in the process of revising T1.231. That WG has, among other things, - added pointer justification stats for SONET; - adjusted the SES thresholds again. I'm not sure if you want to include all (or any) of these items, but in case you want more information a URL for the current T1.231 draft is: ftp://ftp.t1.org/pub/t1m1/m1.3/7m130112.zip The contribution number is T1M1.3/97-011R2 and the file is a pkzip'ed Word for Windows document. Mike -- C. M. Heard VVNET, Inc. phone: +1 408 247 9376 4040 Moorpark Ave. Suite 206 fax: +1 408 244 3651 San Jose, CA 95117 USA e-mail: heard@vvnet.com   Received: from cnri by ietf.org id aa26682; 18 Mar 97 11:30 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa13494; 18 Mar 97 11:30 EST Received: from tbird.cc.bellcore.com (tbird.cc.bellcore.com [128.96.96.114]) by thumper.bellcore.com (8.8.5/8.8.5) with SMTP id KAA07648 for ; Tue, 18 Mar 1997 10:52:11 -0500 (EST) Received: from joker (joker.bellcore.com) by tbird.cc.bellcore.com with SMTP id AA25600 (5.67b/IDA-1.5 for ); Tue, 18 Mar 1997 10:51:57 -0500 Received: from @joker.bellcore.com (nvc-slip6.cc.bellcore.com) by joker (4.1/4.7) id AA17372; Tue, 18 Mar 97 10:52:41 EST X-Station-Sent-From: joker.bellcore.com Message-Id: <3.0.16.19970318104320.4a9fbb00@joker.bellcore.com> X-Sender: kaj@joker.bellcore.com X-Mailer: Windows Eudora Pro Version 3.0 (16) Date: Tue, 18 Mar 1997 10:43:27 -0500 To: "C. M. Heard/VVNET, Inc." , atommib@thumper.bellcore.com From: Kaj Tesink Subject: Re: SONET/SDH Suppl MIB Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_858717807==_" --=====================_858717807==_ Content-Type: text/plain; charset="us-ascii" At 10:47 PM 3/17/97 -0800, C. M. Heard/VVNET, Inc. wrote: >On Mon, 17 Mar 1997 Kaj Tesink wrote: >> i have still an action item to clone the suppl ds1/ds3 mibs >> for sonet/sdh. since these suppl mibs seem to differ somewhat >> i want to make sure i have the functional requirements right. > >Kaj, > >This got my attention, since I don't follow the trunkmib list and was >not aware of the suppl ds1/ds3 mibs. Looks like I have some reading >to catch up on. Looking in the I-D directory on ds.internic.net I >found what I thought might be a draft of the suppl ds1 mib -- >draft-ietf-trunkmib-ds1-supp-00.txt -- but it turns out that this is >just a note to the effect that the draft has expired and has been deleted. > >Can you tell me where to find the current (draft or published) >suppl ds1/ds3 mibs, so I can look at what it is that needs to >be cloned? > good point; i'll check with fred baker whats going on re: the status of these drafts. i have attached the drafts that i had in my archives; the ds1 is from may 96 and the ds3 is from oct96. >> what about this list: >> >> suppl sonet/sdh mib functions: >> - thresholding >> - day interval counters >> - reset capability >> >> anything else? > >You might want to consider adding failure counts. These are present in >T1.231-1993 but are absent from the SONET mib. Also, please be aware >that an ANSI T1M1.3 working group is in the process of revising T1.231. >That WG has, among other things, > > - added pointer justification stats for SONET; > > - adjusted the SES thresholds again. > >I'm not sure if you want to include all (or any) of these items, but in >case you want more information a URL for the current T1.231 draft is: > > ftp://ftp.t1.org/pub/t1m1/m1.3/7m130112.zip > >The contribution number is T1M1.3/97-011R2 and the file is a pkzip'ed Word >for Windows document. thanks for the very useful pointer. my suggestion is that we work along the following guidelines: - lets mibbify only whats considered to be rather "stable" - rather than mibbifying each and every detail in t1.231 lets do only those that are clearly needed -> this means that i invite concrete proposals on which parameters need to be included in this suppl sonet/sdh mib, possibly with t1.231(rev) reference sections. does this make sense? in the mean time i'll check with the trunkmib group on the status of their stuff. kaj --=====================_858717807==_ Content-Type: text/plain; charset="us-ascii" Content-Disposition: attachment; filename="SUPPLDS1.TXT" Return-Path: Date: Fri, 7 Mar 97 18:35:11 EST X-Station-Sent-From: joker.bellcore.com X-Sender: kaj@joker.bellcore.com To: kaj2 From: Kaj Tesink Subject: draft-ietf-trunkmib-ds1-supp-00.txt Hi, Cynthia. Would you please post this as an Internet-Draft? Thanks, Maria - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - INTERNET-DRAFT DS1 Supplemental MIB May 1996 Definitions of Supplemental Managed Objects for the DS1, E1, DS2 and E2 Interface Types May 31, 1996 Maria Greene Ascom Nexion greene@nexen.com Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as a "work in progress". To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Expires December 1996 [Page 1] INTERNET-DRAFT DS1 Supplemental MIB May 1996 Abstract This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes additional objects that supplement those defined in the Definitions of Managed Objects for the DS1, E1, DS2 and E2 Interface Types document, RFC [1]. This memo specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions. This memo does not specify a standard for the Internet community. 1. The SNMP Network Management Framework The SNMP Network Management Framework presently consists of three major components. They are: o the SMI, described in RFC 1902 [2] - the mechanisms used for describing and naming objects for the purpose of management. o the MIB-II, STD 17, RFC 1213 [3] - the core set of managed objects for the Internet suite of protocols. o the protocol, RFC 1157 [4] and/or RFC 1905 [5], - the protocol for accessing managed objects. The Framework permits new objects to be defined for the purpose of experimentation and evaluation. 1.1. Object Definitions Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the subset of Abstract Syntax Notation One (ASN.1) defined in the SMI. In particular, each object type is named by an OBJECT IDENTIFIER, an administratively assigned name. The object type together with an object instance serves to uniquely identify a specific instantiation of the object. For human convenience, we often use a textual string, termed the descriptor, to also refer to the object type. Expires December 1996 [Page 2] INTERNET-DRAFT DS1 Supplemental MIB May 1996 2. Overview The objects in this supplemental MIB apply to interfaces of types DS1, E1, DS2 and E2. The definitions in this MIB provide an SNMP- compatible interface to the features described in ANSI T1.231 [6] that are not in the existing DS1-MIB [1]. These features include: o thesholding o additional valid data flags o a table for previous and recent day history o objects for resetting parameters In addition, this memo contains a short MIB module containing definitions that are anticipated to be common when similar supplemental MIBs are defined for the DS3/E3 and SONET interface types. Expires December 1996 [Page 3] INTERNET-DRAFT DS1 Supplemental MIB May 1996 3. DS1-SUPP-MIB Definitions DS1-SUPP-MIB DEFINITIONS ::= BEGIN IMPORTS OBJECT-TYPE, MODULE-IDENTITY, Gauge32, Unsigned32, experimental FROM SNMPv2-SMI MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF TruthValue, VariablePointer FROM SNMPv2-TC dsx1LineIndex, dsx1ConfigEntry, dsx1FarEndIntervalEntry FROM DS1-MIB ResetAction, ThreshResetAction FROM WAN-MIB ; ds1SupplementalMIB MODULE-IDENTITY LAST-UPDATED "9605171200Z" -- May 17, 1996 ORGANIZATION "IETF Trunk MIB Working Group" CONTACT-INFO " Maria Greene Ascom Nexion Postal: 289 Great Road Acton, MA 01721-4739 US Tel: +1 508 266 4500 E-mail: greene@nexen.com" DESCRIPTION "The MIB module containing definitions for DS1, E1, DS2, and E2 interfaces that supplement those in the standard DS1-MIB. (DS1-like interfaces are refered to generically in this memo as 'DS1 interfaces'.) The objects defined in this MIB module were identified by examining ANSI T1.231-1993 and identifying functionality that was not specified in the standard DS1-MIB. In addition, the Bellcore GR-820-CORE document was consulted, specifically to determine the conformance statements. Implementing this MIB is optional in a managed device that has these types of interfaces because of the additional processing and storage capabilities that are required. The management functions described in this memo are particularly appropriate for 'mediation devices' associated with managed device. (See ANSI T1.231-1993, Section 9.1.2.)" Expires December 1996 [Page 4] INTERNET-DRAFT DS1 Supplemental MIB May 1996 ::= { experimental XX } -- Should be replaced with: -- ::= { ds1 16 } dsx1SuppObjects OBJECT IDENTIFIER ::= { ds1SupplementalMIB 1 } dsx1SuppConfigGroup OBJECT IDENTIFIER ::= { dsx1SuppObjects 1 } -- -- The DS1 Supplemental Configuration Table -- dsx1SuppConfigTable OBJECT-TYPE SYNTAX SEQUENCE OF Dsx1SuppConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains additional configuration objects for a DS1 interface. Specifically, it contains flags indicating whether the associated data table entry contains valid data. The table will have as many rows as there are DS1 interfaces in the system." REFERENCE "ANSI T1.231-1993, Section 9.1.2.2, Bellcore GR-820-CORE, Section 3.2.2, R3-10." ::= { dsx1SuppConfigGroup 1 } dsx1SuppConfigEntry OBJECT-TYPE SYNTAX Dsx1SuppConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Configuration objects for a particular DS1 interface. This entry augments, or extends, the dsx1ConfigEntry defined in the DS1-MIB." AUGMENTS { dsx1ConfigEntry } ::= { dsx1SuppConfigTable 1 } Dsx1SuppConfigEntry ::= SEQUENCE { dsx1CurrentValidData TruthValue, dsx1TotalValidData TruthValue, dsx1FarEndCurrentValidData TruthValue, dsx1FarEndTotalValidData TruthValue } dsx1CurrentValidData OBJECT-TYPE Expires December 1996 [Page 5] INTERNET-DRAFT DS1 Supplemental MIB May 1996 SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates if there is valid data in the dsx1CurrentEntry for this DS1 interface." ::= { dsx1SuppConfigEntry 1 } dsx1TotalValidData OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates if there is valid data in the dsx1TotalEntry for this DS1 interface." ::= { dsx1SuppConfigEntry 2 } dsx1FarEndCurrentValidData OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates if there is valid data in the dsx1FarEndCurrentEntry for this DS1 interface." ::= { dsx1SuppConfigEntry 3 } dsx1FarEndTotalValidData OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates if there is valid data in the dsx1FarEndTotalEntry for this DS1 interface." ::= { dsx1SuppConfigEntry 4 } -- -- DS1 Supplemental Far End Interval Table -- dsx1SuppFarEndIntervalTable OBJECT-TYPE SYNTAX SEQUENCE OF Dsx1SuppFarEndIntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The DS1 Supplemental Far End Interval Table contains a valid data flag for the statistics collected by each DS1 Interface over the previous 24 hours of operation. The past 24 hours Expires December 1996 [Page 6] INTERNET-DRAFT DS1 Supplemental MIB May 1996 are broken into 96 completed 15 minute intervals." ::= { dsx1SuppConfigGroup 2 } dsx1SuppFarEndIntervalEntry OBJECT-TYPE SYNTAX Dsx1SuppFarEndIntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The valid data flag for a DS1 interface for a particular interval." AUGMENTS { dsx1FarEndIntervalEntry } ::= { dsx1SuppFarEndIntervalTable 1 } Dsx1SuppFarEndIntervalEntry ::= SEQUENCE { dsx1FarEndIntervalValidData TruthValue } dsx1FarEndIntervalValidData OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates if there is valid data for this interval." ::= { dsx1SuppFarEndIntervalEntry 1 } -- -- The Threshold Group -- -- NOTE: threshold values do not need to be saved across -- resets/power-ups. dsx1ThresholdGroup OBJECT IDENTIFIER ::= { dsx1SuppObjects 2 } dsx1ResetAllParameters OBJECT-TYPE SYNTAX ResetAction MAX-ACCESS read-write STATUS current DESCRIPTION "Setting this object to the value 'reset(2)' will have have the effect of initializing all parameter values in all entries in the following tables to 0: o dsx1CurrentTable o dsx1TotalTable o dsx1FarEndCurrentTable o dsx1FarEndTotalTable Expires December 1996 [Page 7] INTERNET-DRAFT DS1 Supplemental MIB May 1996 And will destroy all rows in the following tables: o dsx1IntervalTable o dsx1FarEndIntervalTable o dsx1DayIntervalTable o dsx1FarEndDayIntervalTable When read, this object always returns the value 'ready(1)'. In general, allowing objects that are statistics to be reset to 0 is highly discouraged in SNMP MIBs. This is primarily because there may be multiple managers monitoring a given agent. The physical layer performance parameters are already exceptional, however, because they are hybrid counter/gauges: they behave as counters within a given interval and then automatically reset to 0 after the interval is over. Unlike when polling counters, a manager would not get 'confused' by the value of a performance parameter going back to 0. Also, the ability to reset performance parameters is stated as a firm requirement in the reference documents and not allowing reset would make it difficult to implement the required thresholding behavior of only sending one Threshold Crossing Alert (TCA) message in a given interval unless the parameters are reset." REFERENCE "ANSI T1.231-1993, Section 9.1.5.1, Bellcore GR-820-CORE, Section 3.2.2, O3-3" ::= { dsx1ThresholdGroup 1 } dsx1ResetParameter OBJECT-TYPE SYNTAX VariablePointer MAX-ACCESS read-write STATUS current DESCRIPTION "Setting this object to the fully qualified OBJECT IDENTIFIER of a performance parameter will initialize that parameter to 0. For example, setting the value to the OID corresponding to dsx1CurrentSESs.2 will reset that parameter for the DS1 interface with ifIndex value 2. The OBJECT IDENTIFIER and the instance must correspond to a DS1 performance parameter and a DS1 interface in order for the set to succeed." REFERENCE "ANSI T1.231-1993, Section 9.1.5.1, Bellcore GR-820-CORE, Section 3.2.2, O3-3" ::= { dsx1ThresholdGroup 2 } dsx1SuppressAllTcas OBJECT-TYPE Expires December 1996 [Page 8] INTERNET-DRAFT DS1 Supplemental MIB May 1996 SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This object is used to suppress or enable the sending of Threshold Crossing Alerts (TCAs) for the entire agent. The value 'true(1)' supresses TCAs and the value 'false(2)' enables them. By default, agents should initialize this object to 'false(2)' (TCAs are enabled)." REFERENCE "ANSI T1.231-1993, 9.1.5.2" DEFVAL { false } ::= { dsx1ThresholdGroup 3 } dsx1ResetAllThresholds OBJECT-TYPE SYNTAX ThreshResetAction MAX-ACCESS read-write STATUS current DESCRIPTION "This object is used to reset all threshold values for all DS1 interfaces to default or specific values in one action. When read, this object always returns the value 'ready(1)'. When set to 'resetToSpecific(2)', all values are set to the value specified in the 'specific values entry' in the same table. The 'specific values entry' is an entry in the table indexed by the maximum value of the index object. When set to 'resetToDefault(3)', all threshold values are set back to their 'factory default' values, except those of the 'specific values entry'." REFERENCE "ANSI T1.231-1993, 9.1.5.2" ::= { dsx1ThresholdGroup 4 } dsx1ThresholdConfigTable OBJECT-TYPE SYNTAX SEQUENCE OF Dsx1ThresholdConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains additional configuration objects for a DS1 interface that control the over-all thresholding capability for the interface. The table will have as many rows as there are DS1 interfaces in the system." ::= { dsx1ThresholdGroup 5 } dsx1ThresholdConfigEntry OBJECT-TYPE SYNTAX Dsx1ThresholdConfigEntry MAX-ACCESS not-accessible Expires December 1996 [Page 9] INTERNET-DRAFT DS1 Supplemental MIB May 1996 STATUS current DESCRIPTION "Threshold configuration objects for a particular DS1 interface. This entry augments, or extends, the dsx1ConfigEntry defined in the DS1-MIB." AUGMENTS { dsx1ConfigEntry } ::= { dsx1ThresholdConfigTable 1 } Dsx1ThresholdConfigEntry ::= SEQUENCE { dsx1ResetNearEndCurrent ResetAction, dsx1ResetNearEndTotal ResetAction, dsx1ResetNearEndAll ResetAction, dsx1ResetFarEndCurrent ResetAction, dsx1ResetFarEndTotal ResetAction, dsx1ResetFarEndAll ResetAction, dsx1SuppressTca TruthValue, dsx1ResetThresholds ThreshResetAction } dsx1ResetNearEndCurrent OBJECT-TYPE SYNTAX ResetAction MAX-ACCESS read-write STATUS current DESCRIPTION "When set to the value 'reset(2)', the parameters in the dsx1CurrentTable for this interface are reset to 0. Resetting parameters will cause the corresponding instance of dsx1CurrentValidData to be set to 'false(2)'. Note that resetting parameters also resets the dsx1TimeElapsed object to 0, but that it does not effect the total interval duration. In other words, dsx1TimeElapsed will only reach its maximum value of 899 seconds (15 minutes) if parameters were never reset in the interval. When read, this object always returns the value 'ready(1)'." ::= { dsx1ThresholdConfigEntry 1 } dsx1ResetNearEndTotal OBJECT-TYPE SYNTAX ResetAction MAX-ACCESS read-write STATUS current DESCRIPTION "When set to the value 'reset(2)', the parameters in the dsx1TotalTable for this interface are reset to 0. Resetting parameters will cause the corresponding instance of dsx1TotalValidData to be set to 'false(2)'. When read, this object always returns the value 'ready(1)'." Expires December 1996 [Page 10] INTERNET-DRAFT DS1 Supplemental MIB May 1996 ::= { dsx1ThresholdConfigEntry 2 } dsx1ResetNearEndAll OBJECT-TYPE SYNTAX ResetAction MAX-ACCESS read-write STATUS current DESCRIPTION "When this object is set to the value 'reset(2)', the parameters in the following tables are reset to 0: o dsx1CurrentTable o dsx1TotalTable And all rows this these tables are destroyed: o dsx1IntervalTable o dsx1DayIntervalTable. Resetting parameters using this object will cause the corresponding instance of dsx1CurrentValidData and dsx1TotalValidData to be set to 'false(2)' and will reset dsx1TimeElapsed. When read, this object always returns the value 'ready(1)'." ::= { dsx1ThresholdConfigEntry 3 } dsx1ResetFarEndCurrent OBJECT-TYPE SYNTAX ResetAction MAX-ACCESS read-write STATUS current DESCRIPTION "When set to the value 'reset(2)', the parameters in the dsx1FarEndCurrentTotalTable for this interface are reset to 0. Resetting parameters will cause the corresponding instance of dsx1FarEndCurrentValidData to be set to 'false(2)'. When read, this object always returns the value 'ready(1)'." ::= { dsx1ThresholdConfigEntry 4 } dsx1ResetFarEndTotal OBJECT-TYPE SYNTAX ResetAction MAX-ACCESS read-write STATUS current DESCRIPTION "When set to the value 'reset(2)', the parameters in the dsx1FarEndTotalTotalTable for this interface are reset to 0. Resetting parameters will cause the corresponding instance of dsx1FarEndTotalValidData to be set to 'false(2)'. When read, this object always returns the value 'ready(1)'." ::= { dsx1ThresholdConfigEntry 5 } Expires December 1996 [Page 11] INTERNET-DRAFT DS1 Supplemental MIB May 1996 dsx1ResetFarEndAll OBJECT-TYPE SYNTAX ResetAction MAX-ACCESS read-write STATUS current DESCRIPTION "When this object is set to the value 'reset(2)', the parameters in the following tables are reset to 0: o dsx1FarEndCurrentTable o dsx1FarEndTotalTable And all rows this these tables are destroyed: o dsx1FarEndIntervalTable o dsx1FarEndDayIntervalTable. Resetting parameters using this object will cause the corresponding instance of dsx1FarEndCurrentValidData and dsx1FarEndTotalValidData to be set to 'false(2)'. When read, this object always returns the value 'ready(1)'." ::= { dsx1ThresholdConfigEntry 6 } dsx1SuppressTca OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This object is used to suppress or enable the sending of Threshold Crossing Alerts (TCAs) for a particular DS1 interface. The value 'true(1)' supresses TCAs and the value 'false(2)' enables them. By default, agents should initialize this object to 'false(2)' (TCAs are enabled for this interface). Note that if the value of dsx1SuppressAllTcas is 'true(1)', this per-interface object is ignored." REFERENCE "ANSI T1.231-1993, 9.1.5.2" DEFVAL { false } ::= { dsx1ThresholdConfigEntry 7 } dsx1ResetThresholds OBJECT-TYPE SYNTAX ThreshResetAction MAX-ACCESS read-write STATUS current DESCRIPTION "This object is used to reset all threshold values for this DS1 interface to default or specific values in one action. When read, this object always returns the value 'ready(1)'. When set to 'resetToSpecific(2)', all values are Expires December 1996 [Page 12] INTERNET-DRAFT DS1 Supplemental MIB May 1996 set to the value specified in the 'specific values entry' in the same table. The 'specific values entry' is an entry in the table indexed by the maximum value of the index object. When set to 'resetToDefault(3)', all threshold values are set back to their 'factory default' values, except those of the 'specific values entry'." REFERENCE "ANSI T1.231-1993, 9.1.5.2" ::= { dsx1ThresholdConfigEntry 8 } -- -- Current 15 Minute Interval Thresholds -- dsx1CurrentThresholdTable OBJECT-TYPE SYNTAX SEQUENCE OF Dsx1CurrentThresholdEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Thresholds on parameters for the current 15 minute interval per interface." REFERENCE "ANSI T1.231-1993, 9.1.5.2" ::= { dsx1ThresholdGroup 6 } dsx1CurrentThresholdEntry OBJECT-TYPE SYNTAX Dsx1CurrentThresholdEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Thresholds for the current 15 minute interval for a particular interface. If thesholding is not supported on a particular parameter, the error 'noSuchObject' should be returned." INDEX { dsx1CurrentThresholdLineIndex } ::= { dsx1CurrentThresholdTable 1 } Dsx1CurrentThresholdEntry ::= SEQUENCE { dsx1CurrentThresholdLineIndex Unsigned32, dsx1CurrentThresholdESs Gauge32, dsx1CurrentThresholdSESs Gauge32, dsx1CurrentThresholdSEFSs Gauge32, dsx1CurrentThresholdUASs Gauge32, dsx1CurrentThresholdCSSs Gauge32, dsx1CurrentThresholdPCVs Gauge32, dsx1CurrentThresholdLESs Gauge32, dsx1CurrentThresholdLCVs Gauge32 Expires December 1996 [Page 13] INTERNET-DRAFT DS1 Supplemental MIB May 1996 } dsx1CurrentThresholdLineIndex OBJECT-TYPE SYNTAX Unsigned32 (0..2147483648) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The value of ifIndex for the DS1 interface, 0 or 2147483648 (which is 1 greater than the maximum value of ifIndex). The threshold values associated with the row indexed by 2147483648 are the default threshold values. Setting the threshold values associated with the row indexed by 0 updates all DS1 interfaces threshold values to this value. Setting an object with any other value index sets the threshold for just the DS1 interface with that value of ifIndex." ::= { dsx1CurrentThresholdEntry 1 } dsx1CurrentThresholdESs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-write STATUS current DESCRIPTION "A threshold on the number of Errored Seconds encountered by a DS1 interface in the current 15 minute interval." DEFVAL { 65 } ::= { dsx1CurrentThresholdEntry 2 } dsx1CurrentThresholdSESs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-write STATUS current DESCRIPTION "A threshold on the number of Severely Errored Seconds encountered by a DS1 interface in the current 15 minute interval." DEFVAL { 10 } ::= { dsx1CurrentThresholdEntry 3 } dsx1CurrentThresholdSEFSs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-write STATUS current DESCRIPTION "A threshold on the number of Severely Errored Framing Seconds encountered by a DS1 interface in the current 15 minute interval." DEFVAL { 2 } Expires December 1996 [Page 14] INTERNET-DRAFT DS1 Supplemental MIB May 1996 ::= { dsx1CurrentThresholdEntry 4 } dsx1CurrentThresholdUASs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-write STATUS current DESCRIPTION "A threshold on the number of Unavailable Seconds encountered by a DS1 interface in the current 15 minute interval." DEFVAL { 10 } ::= { dsx1CurrentThresholdEntry 5 } dsx1CurrentThresholdCSSs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-write STATUS current DESCRIPTION "A threshold on the number of Controlled Slip Seconds encountered by a DS1 interface in the current 15 minute interval." DEFVAL { 1 } ::= { dsx1CurrentThresholdEntry 6 } dsx1CurrentThresholdPCVs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-write STATUS current DESCRIPTION "A threshold on the number of Path Coding Violations encountered by a DS1 interface in the current 15 minute interval." DEFVAL { 13296 } ::= { dsx1CurrentThresholdEntry 7 } dsx1CurrentThresholdLESs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-write STATUS current DESCRIPTION "A threshold on the number of Line Errored Seconds encountered by a DS1 interface in the current 15 minute interval." DEFVAL { 65 } ::= { dsx1CurrentThresholdEntry 8 } dsx1CurrentThresholdLCVs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-write Expires December 1996 [Page 15] INTERNET-DRAFT DS1 Supplemental MIB May 1996 STATUS current DESCRIPTION "A threshold on the number of Line Code Violations (LCVs) encountered by a DS1 interface in the current 15 minute interval." DEFVAL { 13340 } ::= { dsx1CurrentThresholdEntry 9 } -- -- Far End, Current 15 Minute Interval Thresholds -- dsx1FarEndCurrentThresholdTable OBJECT-TYPE SYNTAX SEQUENCE OF Dsx1FarEndCurrentThresholdEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Thresholds on far end parameters for the current 15 minute interval per interface." ::= { dsx1ThresholdGroup 7 } dsx1FarEndCurrentThresholdEntry OBJECT-TYPE SYNTAX Dsx1FarEndCurrentThresholdEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Thresholds on far end parameters for the current 15 minute interval for a particular interface. If thesholding is not supported on a particular parameter, the error 'noSuchObject' should be returned." INDEX { dsx1FarEndCurrentThresholdLineIndex } ::= { dsx1FarEndCurrentThresholdTable 1 } Dsx1FarEndCurrentThresholdEntry ::= SEQUENCE { dsx1FarEndCurrentThresholdLineIndex Unsigned32, dsx1FarEndCurrentThresholdESs Gauge32, dsx1FarEndCurrentThresholdSESs Gauge32, dsx1FarEndCurrentThresholdSEFSs Gauge32, dsx1FarEndCurrentThresholdUASs Gauge32, dsx1FarEndCurrentThresholdCSSs Gauge32, dsx1FarEndCurrentThresholdPCVs Gauge32, dsx1FarEndCurrentThresholdLESs Gauge32, dsx1FarEndCurrentThresholdLCVs Gauge32 } dsx1FarEndCurrentThresholdLineIndex OBJECT-TYPE SYNTAX Unsigned32 (0..2147483648) Expires December 1996 [Page 16] INTERNET-DRAFT DS1 Supplemental MIB May 1996 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The value of ifIndex for the DS1 interface, 0 or 2147483648 (which is 1 greater than the maximum value of ifIndex). The threshold values associated with the row indexed by 2147483648 are the default threshold values. The threshold values associated with the row indexed by 0 updates all DS1 interfaces threshold values to this value. Setting an object with any other value index sets the threshold for just the DS1 interface with that value of ifIndex." ::= { dsx1FarEndCurrentThresholdEntry 1 } dsx1FarEndCurrentThresholdESs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-write STATUS current DESCRIPTION "A threshold on the number of Errored Seconds encountered by the far end of a DS1 interface in the current 15 minute interval." DEFVAL { 65 } ::= { dsx1FarEndCurrentThresholdEntry 2 } dsx1FarEndCurrentThresholdSESs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-write STATUS current DESCRIPTION "A threshold on the number of Severely Errored Seconds encountered by the far end of a DS1 interface in the current 15 minute interval." DEFVAL { 10 } ::= { dsx1FarEndCurrentThresholdEntry 3 } dsx1FarEndCurrentThresholdSEFSs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-write STATUS current DESCRIPTION "A threshold on the number of Severely Errored Framing Seconds encountered by the far end of a DS1 interface in the current 15 minute interval." DEFVAL { 2 } ::= { dsx1FarEndCurrentThresholdEntry 4 } dsx1FarEndCurrentThresholdUASs OBJECT-TYPE SYNTAX Gauge32 Expires December 1996 [Page 17] INTERNET-DRAFT DS1 Supplemental MIB May 1996 MAX-ACCESS read-write STATUS current DESCRIPTION "A threshold on the number of Unavailable Seconds encountered by the far end of a DS1 interface in the current 15 minute interval." DEFVAL { 10 } ::= { dsx1FarEndCurrentThresholdEntry 5 } dsx1FarEndCurrentThresholdCSSs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-write STATUS current DESCRIPTION "A threshold on the number of Controlled Slip Seconds encountered by the far end of a DS1 interface in the current 15 minute interval." DEFVAL { 1 } ::= { dsx1FarEndCurrentThresholdEntry 6 } dsx1FarEndCurrentThresholdPCVs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-write STATUS current DESCRIPTION "A threshold on the number of Path Coding Violations encountered by the far end of a DS1 interface in the current 15 minute interval." DEFVAL { 13296 } ::= { dsx1FarEndCurrentThresholdEntry 7 } dsx1FarEndCurrentThresholdLESs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-write STATUS current DESCRIPTION "A threshold on the number of Line Errored Seconds encountered by the far end of a DS1 interface in the current 15 minute interval." DEFVAL { 65 } ::= { dsx1FarEndCurrentThresholdEntry 8 } dsx1FarEndCurrentThresholdLCVs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-write STATUS current DESCRIPTION "A threshold on the number of Line Code Violations (LCVs) encountered by the far end of a DS1 interface in the current 15 minute Expires December 1996 [Page 18] INTERNET-DRAFT DS1 Supplemental MIB May 1996 interval." DEFVAL { 13340 } ::= { dsx1FarEndCurrentThresholdEntry 9 } -- -- 24 Hour Interval Thresholds -- dsx1TotalThresholdTable OBJECT-TYPE SYNTAX SEQUENCE OF Dsx1TotalThresholdEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Thresholds on parameters for the current 24 hour interval per interface." ::= { dsx1ThresholdGroup 8 } dsx1TotalThresholdEntry OBJECT-TYPE SYNTAX Dsx1TotalThresholdEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Thresholds on parameters for the current 24 hour interval for a particular interface. If thesholding is not supported on a particular parameter, the error 'noSuchObject' should be returned." INDEX { dsx1TotalThresholdLineIndex } ::= { dsx1TotalThresholdTable 1 } Dsx1TotalThresholdEntry ::= SEQUENCE { dsx1TotalThresholdLineIndex Unsigned32, dsx1TotalThresholdESs Gauge32, dsx1TotalThresholdSESs Gauge32, dsx1TotalThresholdSEFSs Gauge32, dsx1TotalThresholdUASs Gauge32, dsx1TotalThresholdCSSs Gauge32, dsx1TotalThresholdPCVs Gauge32, dsx1TotalThresholdLESs Gauge32, dsx1TotalThresholdLCVs Gauge32 } dsx1TotalThresholdLineIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The value of ifIndex for the DS1 interface, 0 or 2147483648 Expires December 1996 [Page 19] INTERNET-DRAFT DS1 Supplemental MIB May 1996 (which is 1 greater than the maximum value of ifIndex). The threshold values associated with the row indexed by 2147483648 are the default threshold values. The threshold values associated with the row indexed by 0 updates all DS1 interfaces threshold values to this value. Setting an object with any other value index sets the threshold for just the DS1 interface with that value of ifIndex." ::= { dsx1TotalThresholdEntry 1 } dsx1TotalThresholdESs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-write STATUS current DESCRIPTION "A threshold on the number of Errored Seconds encountered by _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ _/ _/ _/ Kaj Tesink _/ _/ Bellcore _/ _/ - Emerging Networks vmail (908) 758-5254 _/ _/ 331 Newman Springs Rd. email kaj@cc.bellcore.com _/ _/ Red Bank, NJ 07701 faxmail (908) 758-4177 _/ _/ _/ _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Return-Path: Date: Fri, 7 Mar 97 18:35:15 EST X-Station-Sent-From: joker.bellcore.com X-Sender: kaj@joker.bellcore.com To: kaj2 From: Kaj Tesink Subject: draft-ietf-trunkmib-ds1-supp-00.txt/2 a DS1 interface in the current 24 hour interval." DEFVAL { 648 } ::= { dsx1TotalThresholdEntry 2 } dsx1TotalThresholdSESs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-write STATUS current DESCRIPTION "A threshold on the number of Severely Errored Seconds encountered by a DS1 interface in the current 24 hour interval." DEFVAL { 100 } ::= { dsx1TotalThresholdEntry 3 } dsx1TotalThresholdSEFSs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-write STATUS current DESCRIPTION "A threshold on the number of Severely Errored Framing Seconds encountered by a DS1 interface in the current 24 hour interval." DEFVAL { 17 } ::= { dsx1TotalThresholdEntry 4 } dsx1TotalThresholdUASs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-write STATUS current DESCRIPTION "A threshold on the number of Unavailable Seconds encountered Expires December 1996 [Page 20] INTERNET-DRAFT DS1 Supplemental MIB May 1996 by a DS1 interface in the current 24 hour interval." DEFVAL { 10 } ::= { dsx1TotalThresholdEntry 5 } dsx1TotalThresholdCSSs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-write STATUS current DESCRIPTION "A threshold on the number of Controlled Slip Seconds encountered by a DS1 interface in the current 24 hour interval." DEFVAL { 4 } ::= { dsx1TotalThresholdEntry 6 } dsx1TotalThresholdPCVs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-write STATUS current DESCRIPTION "A threshold on the number of Path Coding Violations encountered by a DS1 interface in the current 24 hour interval." DEFVAL { 132960 } ::= { dsx1TotalThresholdEntry 7 } dsx1TotalThresholdLESs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-write STATUS current DESCRIPTION "A threshold on the number of Line Errored Seconds encountered by a DS1 interface in the current 24 hour interval." DEFVAL { 648 } ::= { dsx1TotalThresholdEntry 8 } dsx1TotalThresholdLCVs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-write STATUS current DESCRIPTION "A threshold on the number of Line Code Violations (LCVs) encountered by a DS1 interface in the current 24 hour interval." DEFVAL { 133400 } ::= { dsx1TotalThresholdEntry 9 } Expires December 1996 [Page 21] INTERNET-DRAFT DS1 Supplemental MIB May 1996 -- -- Far End 24 Hour Interval Thresholds -- dsx1FarEndTotalThresholdTable OBJECT-TYPE SYNTAX SEQUENCE OF Dsx1FarEndTotalThresholdEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Thresholds on far end parameters for the current 24 hour interval per interface." ::= { dsx1ThresholdGroup 9 } dsx1FarEndTotalThresholdEntry OBJECT-TYPE SYNTAX Dsx1FarEndTotalThresholdEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Thresholds on far end parameters for the current 24 hour interval for a particular interface. If thesholding is not supported on a particular parameter, the error 'noSuchObject' should be returned." INDEX { dsx1FarEndTotalThresholdLineIndex } ::= { dsx1FarEndTotalThresholdTable 1 } Dsx1FarEndTotalThresholdEntry ::= SEQUENCE { dsx1FarEndTotalThresholdLineIndex Unsigned32, dsx1FarEndTotalThresholdESs Gauge32, dsx1FarEndTotalThresholdSESs Gauge32, dsx1FarEndTotalThresholdSEFSs Gauge32, dsx1FarEndTotalThresholdUASs Gauge32, dsx1FarEndTotalThresholdCSSs Gauge32, dsx1FarEndTotalThresholdPCVs Gauge32, dsx1FarEndTotalThresholdLESs Gauge32, dsx1FarEndTotalThresholdLCVs Gauge32 } dsx1FarEndTotalThresholdLineIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The value of ifIndex for the DS1 interface, 0 or 2147483648 (which is 1 greater than the maximum value of ifIndex). The threshold values associated with the row indexed by 2147483648 are the default threshold values. The threshold values associated with the row indexed by 0 updates all DS1 Expires December 1996 [Page 22] INTERNET-DRAFT DS1 Supplemental MIB May 1996 interfaces threshold values to this value. Setting an object with any other value index sets the threshold for just the DS1 interface with that value of ifIndex." ::= { dsx1FarEndTotalThresholdEntry 1 } dsx1FarEndTotalThresholdESs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-write STATUS current DESCRIPTION "A threshold on the number of Errored Seconds encountered by the far end of a DS1 interface in the current 24 hour interval." DEFVAL { 648 } ::= { dsx1FarEndTotalThresholdEntry 2 } dsx1FarEndTotalThresholdSESs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-write STATUS current DESCRIPTION "A threshold on the number of Severely Errored Seconds encountered by the far end of a DS1 interface in the current 24 hour interval." DEFVAL { 100 } ::= { dsx1FarEndTotalThresholdEntry 3 } dsx1FarEndTotalThresholdSEFSs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-write STATUS current DESCRIPTION "A threshold on the number of Severely Errored Framing Seconds encountered by the far end of a DS1 interface in the current 24 hour interval." DEFVAL { 17 } ::= { dsx1FarEndTotalThresholdEntry 4 } dsx1FarEndTotalThresholdUASs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-write STATUS current DESCRIPTION "A threshold on the number of Unavailable Seconds encountered by the far end of a DS1 interface in the current 24 hour interval." DEFVAL { 10 } Expires December 1996 [Page 23] INTERNET-DRAFT DS1 Supplemental MIB May 1996 ::= { dsx1FarEndTotalThresholdEntry 5 } dsx1FarEndTotalThresholdCSSs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-write STATUS current DESCRIPTION "A threshold on the number of Controlled Slip Seconds encountered by the far end of a DS1 interface in the current 24 hour interval." DEFVAL { 4 } ::= { dsx1FarEndTotalThresholdEntry 6 } dsx1FarEndTotalThresholdPCVs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-write STATUS current DESCRIPTION "A threshold on the number of Path Coding Violations encountered by the far end of a DS1 interface in the current 24 hour interval." DEFVAL { 132960 } ::= { dsx1FarEndTotalThresholdEntry 7 } dsx1FarEndTotalThresholdLESs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-write STATUS current DESCRIPTION "A threshold on the number of Line Errored Seconds encountered by the far end of a DS1 interface in the current 24 hour interval." DEFVAL { 648 } ::= { dsx1FarEndTotalThresholdEntry 8 } dsx1FarEndTotalThresholdLCVs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-write STATUS current DESCRIPTION "A threshold on the number of Line Code Violations (LCVs) encountered by the far end of a DS1 interface in the current 24 hour interval." DEFVAL { 133400 } ::= { dsx1FarEndTotalThresholdEntry 9 } -- Expires December 1996 [Page 24] INTERNET-DRAFT DS1 Supplemental MIB May 1996 -- The Day Interval Group dsx1DayIntervalGroup OBJECT IDENTIFIER ::= { dsx1SuppObjects 3 } dsx1DayIntervalMax OBJECT-TYPE SYNTAX INTEGER (1..7) MAX-ACCESS read-write STATUS current DESCRIPTION "The number of entries that will be maintained in the dsx1DayIntervalTable and dsx1FarEndDayIntervalTable for each DS1 interface. Setting the object to a value lower than the current number of entries in the tables causes the entries beyond the max value to be destroyed." REFERENCE "ANSI T1.231-1993, Section 9.2.1.2, Bellcore GR-820-CORE, Section 4.7.3." DEFVAL { 1 } ::= { dsx1DayIntervalGroup 1 } dsx1DayIntervalStart OBJECT-TYPE SYNTAX INTEGER (0..23) MAX-ACCESS read-write STATUS current DESCRIPTION "For daily data, the hour when to begin measuring the daily period for the purpose of reporting data. Note that this object is optional because SNMP agents are not required to have an internal 'wall clock'." REFERENCE "ANSI T1.231-1993, Section 9.1.5.1 Bellcore GR-820-CORE, Section 3.2.2, R3-16" DEFVAL { 0 } ::= { dsx1DayIntervalGroup 2 } -- -- DS1 Day Interval Table -- dsx1DayIntervalTable OBJECT-TYPE SYNTAX SEQUENCE OF Dsx1DayIntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of up to dsx1DayIntervalMax days DS1 statistic totals for each interface. These totals record up to one week's worth of cumulative statistics." Expires December 1996 [Page 25] INTERNET-DRAFT DS1 Supplemental MIB May 1996 ::= { dsx1DayIntervalGroup 3 } dsx1DayIntervalEntry OBJECT-TYPE SYNTAX Dsx1DayIntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "One recent day's worth of DS1 statistic totals for an interface." INDEX { dsx1LineIndex, dsx1DayIntervalNumber } ::= { dsx1DayIntervalTable 1 } Dsx1DayIntervalEntry ::= SEQUENCE { dsx1DayIntervalNumber INTEGER, dsx1DayIntervalESs Gauge32, dsx1DayIntervalSESs Gauge32, dsx1DayIntervalSEFSs Gauge32, dsx1DayIntervalUASs Gauge32, dsx1DayIntervalCSSs Gauge32, dsx1DayIntervalPCVs Gauge32, dsx1DayIntervalLESs Gauge32, dsx1DayIntervalBESs Gauge32, dsx1DayIntervalDMs Gauge32, dsx1DayIntervalLCVs Gauge32, dsx1DayIntervalValidData TruthValue } dsx1DayIntervalNumber OBJECT-TYPE SYNTAX INTEGER (1..6) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A number between 1 and 6, where 1 is the most recently completed 24 hour interval before the interval represented by the dsx1TotalTable." ::= { dsx1DayIntervalEntry 1 } dsx1DayIntervalESs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Errored Seconds encountered by a DS1 interface in one of the individual 24 hour intervals. In the case where the agent is a proxy and valid data is not available, return noSuchInstance." ::= { dsx1DayIntervalEntry 2 } Expires December 1996 [Page 26] INTERNET-DRAFT DS1 Supplemental MIB May 1996 dsx1DayIntervalSESs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Severely Errored Seconds encountered by a DS1 interface in one of the individual 24 hour intervals. In the case where the agent is a proxy and valid data is not available, return noSuchInstance." ::= { dsx1DayIntervalEntry 3 } dsx1DayIntervalSEFSs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Severely Errored Framing Seconds encountered by a DS1 interface in one of the individual 24 hour intervals. In the case where the agent is a proxy and valid data is not available, return noSuchInstance." ::= { dsx1DayIntervalEntry 4 } dsx1DayIntervalUASs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Unavailable Seconds encountered by a DS1 interface in one of the individual 24 hour intervals. In the case where the agent is a proxy and valid data is not available, return noSuchInstance. This object may decrease if the occurance of unavailable seconds occurs across an inteval boundary." ::= { dsx1DayIntervalEntry 5 } dsx1DayIntervalCSSs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Controlled Slip Seconds encountered by a DS1 interface in one of the individual 24 hour intervals. In the case where the agent is a proxy and valid data is not available, return noSuchInstance." ::= { dsx1DayIntervalEntry 6 } dsx1DayIntervalPCVs OBJECT-TYPE Expires December 1996 [Page 27] INTERNET-DRAFT DS1 Supplemental MIB May 1996 SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Path Coding Violations encountered by a DS1 interface in one of the individual 24 hour intervals. In the case where the agent is a proxy and valid data is not available, return noSuchInstance." ::= { dsx1DayIntervalEntry 7 } dsx1DayIntervalLESs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Line Errored Seconds encountered by a DS1 interface in one of the individual 24 hour intervals. In the case where the agent is a proxy and valid data is not available, return noSuchInstance." ::= { dsx1DayIntervalEntry 8 } dsx1DayIntervalBESs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Bursty Errored Seconds (BESs) encountered by a DS1 interface in one of the individual 24 hour intervals. In the case where the agent is a proxy and valid data is not available, return noSuchInstance." ::= { dsx1DayIntervalEntry 9 } dsx1DayIntervalDMs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Degraded Minutes (DMs) encountered by a DS1 interface in one of the individual 24 hour intervals. In the case where the agent is a proxy and valid data is not available, return noSuchInstance." ::= { dsx1DayIntervalEntry 10 } dsx1DayIntervalLCVs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current Expires December 1996 [Page 28] INTERNET-DRAFT DS1 Supplemental MIB May 1996 DESCRIPTION "The number of Line Code Violations (LCVs) encountered by a DS1 interface in one of the individual 24 hour intervals. In the case where the agent is a proxy and valid data is not available, return noSuchInstance." ::= { dsx1DayIntervalEntry 11 } dsx1DayIntervalValidData OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates if there is valid data for this interval." DEFVAL { true } ::= { dsx1DayIntervalEntry 12 } -- -- DS1 Far End Day Interval Table -- dsx1FarEndDayIntervalTable OBJECT-TYPE SYNTAX SEQUENCE OF Dsx1FarEndDayIntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of up to dsx1DayIntervalMax days DS1 Far End statistic totals for each interface. These totals record up to one week's worth of cumulative statistics." ::= { dsx1DayIntervalGroup 4 } dsx1FarEndDayIntervalEntry OBJECT-TYPE SYNTAX Dsx1FarEndDayIntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "One recent day's worth of Far End statistic totals for an interface." INDEX { dsx1LineIndex, dsx1FarEndDayIntervalNumber } ::= { dsx1FarEndDayIntervalTable 1 } Dsx1FarEndDayIntervalEntry ::= SEQUENCE { dsx1FarEndDayIntervalNumber INTEGER, dsx1FarEndDayIntervalESs Gauge32, dsx1FarEndDayIntervalSESs Gauge32, dsx1FarEndDayIntervalSEFSs Gauge32, dsx1FarEndDayIntervalUASs Gauge32, Expires December 1996 [Page 29] INTERNET-DRAFT DS1 Supplemental MIB May 1996 dsx1FarEndDayIntervalCSSs Gauge32, dsx1FarEndDayIntervalLESs Gauge32, dsx1FarEndDayIntervalPCVs Gauge32, dsx1FarEndDayIntervalBESs Gauge32, dsx1FarEndDayIntervalDMs Gauge32, dsx1FarEndDayIntervalValidData TruthValue } dsx1FarEndDayIntervalNumber OBJECT-TYPE SYNTAX INTEGER (1..6) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A number between 1 and 6, where 1 is the most recently completed 24 hour interval before the one represented by the dsx1FarEndTotalTable." ::= { dsx1FarEndDayIntervalEntry 1 } dsx1FarEndDayIntervalESs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Far End Errored Seconds encountered by a DS1 interface in one of the individual 24 hour intervals. In the case where the agent is a proxy and valid data is not available, return noSuchInstance." ::= { dsx1FarEndDayIntervalEntry 2 } dsx1FarEndDayIntervalSESs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Far End Severely Errored Seconds encountered by a DS1 interface in one of the individual 24 hour intervals. In the case where the agent is a proxy and valid data is not available, return noSuchInstance." ::= { dsx1FarEndDayIntervalEntry 3 } dsx1FarEndDayIntervalSEFSs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Far End Severely Errored Framing Seconds encountered by a DS1 interface in one of the individual 24 Expires December 1996 [Page 30] INTERNET-DRAFT DS1 Supplemental MIB May 1996 hour intervals. In the case where the agent is a proxy and valid data is not available, return noSuchInstance." ::= { dsx1FarEndDayIntervalEntry 4 } dsx1FarEndDayIntervalUASs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Unavailable Seconds encountered by a DS1 interface in one of the individual 24 hour intervals. In the case where the agent is a proxy and valid data is not available, return noSuchInstance." ::= { dsx1FarEndDayIntervalEntry 5 } dsx1FarEndDayIntervalCSSs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Far End Controlled Slip Seconds encountered by a DS1 interface in one of the individual 24 hour intervals. In the case where the agent is a proxy and valid data is not available, return noSuchInstance." ::= { dsx1FarEndDayIntervalEntry 6 } dsx1FarEndDayIntervalLESs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Far End Line Errored Seconds encountered by a DS1 interface in one of the individual 24 hour intervals. In the case where the agent is a proxy and valid data is not available, return noSuchInstance." ::= { dsx1FarEndDayIntervalEntry 7 } dsx1FarEndDayIntervalPCVs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Far End Path Coding Violations reported via the far end block error count encountered by a DS1 interface in one of the individual 24 hour intervals. In the case where the agent is a proxy and valid data is not available, return noSuchInstance." Expires December 1996 [Page 31] INTERNET-DRAFT DS1 Supplemental MIB May 1996 ::= { dsx1FarEndDayIntervalEntry 8 } dsx1FarEndDayIntervalBESs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Bursty Errored Seconds (BESs) encountered by a DS1 interface in one of the individual 24 hour intervals. In the case where the agent is a proxy and valid data is not available, return noSuchInstance." ::= { dsx1FarEndDayIntervalEntry 9 } dsx1FarEndDayIntervalDMs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Degraded Minutes (DMs) encountered by a DS1 interface in one of the individual 24 hour intervals. In the case where the agent is a proxy and valid data is not available, return noSuchInstance." ::= { dsx1FarEndDayIntervalEntry 10 } dsx1FarEndDayIntervalValidData OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates if there is valid data for this interval." ::= { dsx1FarEndDayIntervalEntry 11 } -- -- Module Compliance Statement -- dsx1SuppConformance OBJECT IDENTIFIER ::= { ds1SupplementalMIB 2 } dsx1SuppCompliances OBJECT IDENTIFIER ::= { dsx1SuppConformance 1 } dsx1SuppGroups OBJECT IDENTIFIER ::= { dsx1SuppConformance 2 } dsx1SuppModuleCompliance MODULE-COMPLIANCE STATUS current Expires December 1996 [Page 32] INTERNET-DRAFT DS1 Supplemental MIB May 1996 DESCRIPTION "The compliance statement for the DS1 Supplemental MIB. Note that agents which implement the standard DS1 MIB are not required to implement this MIB as well." MODULE -- this module MANDATORY-GROUPS { dsx1SuppRequiredGroup } OBJECT dsx1DayIntervalMax MIN-ACCESS read-only DESCRIPTION "An agent is not required to support more than one entry in the dsx1DayIntervalTable, representing the previous day's values." GROUP dsx1SuppOptionalGroup DESCRIPTION "Implementation is optional for systems that attach to one or more DS1 interfaces." ::= { dsx1SuppCompliances 1 } dsx1SuppRequiredGroup OBJECT-GROUP OBJECTS { dsx1CurrentValidData, dsx1TotalValidData, dsx1FarEndCurrentValidData, dsx1FarEndTotalValidData, dsx1FarEndIntervalValidData, dsx1SuppressAllTcas, dsx1ResetAllThresholds, dsx1ResetNearEndCurrent, dsx1ResetNearEndTotal, dsx1ResetNearEndAll, dsx1ResetFarEndCurrent, dsx1ResetFarEndTotal, dsx1ResetFarEndAll, dsx1SuppressTca, dsx1ResetThresholds, dsx1CurrentThresholdESs, dsx1CurrentThresholdSESs, dsx1CurrentThresholdSEFSs, dsx1CurrentThresholdUASs, dsx1CurrentThresholdCSSs, dsx1CurrentThresholdPCVs, dsx1CurrentThresholdLESs, dsx1CurrentThresholdLCVs, dsx1FarEndCurrentThresholdESs, dsx1FarEndCurrentThresholdSESs, dsx1FarEndCurrentThresholdSEFSs, Expires December 1996 [Page 33] INTERNET-DRAFT DS1 Supplemental MIB May 1996 dsx1FarEndCurrentThresholdUASs, dsx1FarEndCurrentThresholdCSSs, dsx1FarEndCurrentThresholdPCVs, dsx1FarEndCurrentThresholdLESs, dsx1FarEndCurrentThresholdLCVs, dsx1TotalThresholdESs, dsx1TotalThresholdSESs, dsx1TotalThresholdSEFSs, dsx1TotalThresholdUASs, dsx1TotalThresholdCSSs, dsx1TotalThresholdPCVs, dsx1TotalThresholdLESs, dsx1TotalThresholdLCVs, dsx1FarEndTotalThresholdESs, dsx1FarEndTotalThresholdSESs, dsx1FarEndTotalThresholdSEFSs, dsx1FarEndTotalThresholdUASs, dsx1FarEndTotalThresholdCSSs, dsx1FarEndTotalThresholdPCVs, dsx1FarEndTotalThresholdLESs, dsx1FarEndTotalThresholdLCVs, dsx1DayIntervalMax, dsx1DayIntervalESs, dsx1DayIntervalSESs, dsx1DayIntervalSEFSs, dsx1DayIntervalUASs, dsx1DayIntervalCSSs, dsx1DayIntervalPCVs, dsx1DayIntervalLESs, dsx1DayIntervalBESs, dsx1DayIntervalDMs, dsx1DayIntervalLCVs, dsx1DayIntervalValidData, dsx1FarEndDayIntervalESs, dsx1FarEndDayIntervalSESs, dsx1FarEndDayIntervalSEFSs, dsx1FarEndDayIntervalUASs, dsx1FarEndDayIntervalCSSs, dsx1FarEndDayIntervalLESs, dsx1FarEndDayIntervalPCVs, dsx1FarEndDayIntervalBESs, dsx1FarEndDayIntervalDMs, dsx1FarEndDayIntervalValidData } STATUS current DESCRIPTION "The objects that must be supported by all agents which Expires December 1996 [Page 34] INTERNET-DRAFT DS1 Supplemental MIB May 1996 implement this supplemental MIB." ::= { dsx1SuppGroups 1 } dsx1SuppOptionalGroup OBJECT-GROUP OBJECTS { dsx1ResetAllParameters, dsx1ResetParameter, dsx1DayIntervalStart } STATUS current DESCRIPTION "The objects that optionally may be supported by all agents which implement this supplemental MIB." ::= { dsx1SuppGroups 2 } END Expires December 1996 [Page 35] INTERNET-DRAFT DS1 Supplemental MIB May 1996 4. WAN-MIB Definitions WAN-MIB DEFINITIONS ::= BEGIN IMPORTS OBJECT-TYPE, MODULE-IDENTITY, NOTIFICATION-TYPE, experimental FROM SNMPv2-SMI MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF TEXTUAL-CONVENTION FROM SNMPv2-TC ifIndex FROM IF-MIB ; wanMIB MODULE-IDENTITY LAST-UPDATED "9605171200Z" -- May 17, 1996 ORGANIZATION "IETF Trunk MIB Working Group" CONTACT-INFO " Maria Greene Ascom Nexion Postal: 289 Great Road Acton, MA 01721-4739 US Tel: +1 508 266 4500 Fax: +1 508 266 2300 E-mail: greene@nexen.com" DESCRIPTION "This MIB contains common textual conventions used by the WAN MIBs and the thesholdCrossingAlert NOTIFICATION-TYPE." ::= { experimental 3002 } -- Should be replaced with: -- ::= { transmission xx } ResetAction ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A syntax used for objects that trigger a reset of some type. Setting the value to 'reset(2)' causes the action. When read, objects of this syntax will always return the value 'ready(1)'." SYNTAX INTEGER { ready(1), reset(2) } Expires December 1996 [Page 36] INTERNET-DRAFT DS1 Supplemental MIB May 1996 ThreshResetAction ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A syntax used for objects that reset a group of thresholds." SYNTAX INTEGER { ready(1), resetToSpecific(2), resetToDefault(3) } wanObjects OBJECT IDENTIFIER ::= { wanMIB 1 } wanAudibleAlarmCutOff OBJECT-TYPE SYNTAX ResetAction MAX-ACCESS read-write STATUS current DESCRIPTION "This object is used to turn off an audible local alarm. When read, this object always returns the value 'ready(1)'. When set to the value 'reset(2)', the audible alarm is silenced. Note that resetting the audible alarm indicator does not keep the audible alarm from turning on again if the alarm state re-occurs." ::= { wanObjects 1 } wanTraps OBJECT IDENTIFIER ::= { wanMIB 2 } thresholdCrossingAlert NOTIFICATION-TYPE OBJECTS { ifIndex -- parameter value, threshold value } STATUS current DESCRIPTION "The thresholdCrossingAlert (TCA) notification indicates that a threshold has been crossed for a particular performance parameter for a particular WAN interface. The ifIndex of the WAN interface is included in the variable bindings list of the Trap PDU along with the parameter and the threshold objects. Note that these last two vary based on the parameter and the interval and therefore are not specified explicitly in the OBJECTS list. Note that the sysUpTime and sysTrapOID objects are always included in every Trap PDU's variable bindings list. For each interface, Only one TCA is sent for a given interval (current 15 minutes or current day) per parameter per Expires December 1996 [Page 37] INTERNET-DRAFT DS1 Supplemental MIB May 1996 direction of transmission unless the parameter is reset." ::= { wanTraps 1 } -- -- Module Compliance Statement -- wanConformance OBJECT IDENTIFIER ::= { wanMIB 3 } wanCompliances OBJECT IDENTIFIER ::= { wanConformance 1 } wanGroups OBJECT IDENTIFIER ::= { wanConformance 2 } wanModuleCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for the WAN MIB." MODULE -- this module GROUP wanOptionalGroup DESCRIPTION "This group is required only for agents that support an audible alarm." ::= { wanCompliances 1 } wanOptionalGroup OBJECT-GROUP OBJECTS { wanAudibleAlarmCutOff } STATUS current DESCRIPTION "The only object in this MIB module." ::= { wanGroups 1 } END Expires December 1996 [Page 38] INTERNET-DRAFT DS1 Supplemental MIB May 1996 5. Acknowledgments This document is a product of the IETF's Trunk MIB Working Group. 6. References [1] David Fowler, "Definitions of Managed Objects for the DS1, E1, DS2 and E2 Interface Types", RFC, Newbridge Networks, March 1996. [2] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC1902, SNMP Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [3] McCloghrie, K., and M. Rose, Editors, "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", STD 17, RFC 1213, Hughes LAN Systems, Performance Systems International, March 1991. [4] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", RFC 1157, SNMP Research, Performance Systems International, Performance Systems International, MIT Laboratory for Computer Science, May 1990. [5] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC1905, SNMP Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [6] American National Standard for Telecommunications, "Digital Hierarchy -- Layer 1 In-Service Digital Transmission Performance Monitoring", T1.231, September 1993. [7] Bellcore, "Generic Digital Transmission Surveillance, A Module of OTGR, FR-NWT-000439", GR-820-CORE, Issue 1, November 1994. Expires December 1996 [Page 39] INTERNET-DRAFT DS1 Supplemental MIB May 1996 7. Security Considerations Security issues are not discussed in this memo. 8. Author's Address Maria Greene Ascom Nexion 289 Great Road Acton, MA 01720-4739 Phone: (508) 266-4570 EMail: greene@nexen.com Expires December 1996 [Page 40] INTERNET-DRAFT DS1 Supplemental MIB May 1996 Table of Contents 1 The SNMP Network Management Framework ........................ 2 1.1 Object Definitions ......................................... 2 2 Overview ..................................................... 3 3 DS1-SUPP-MIB Definitions ..................................... 4 4 WAN-MIB Definitions .......................................... 36 5 Acknowledgments .............................................. 39 6 References ................................................... 39 7 Security Considerations ...................................... 40 8 Author's Address ............................................. 40 Expires December 1996 [Page 41] _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ _/ _/ _/ Kaj Tesink _/ _/ Bellcore _/ _/ - Emerging Networks vmail (908) 758-5254 _/ _/ 331 Newman Springs Rd. email kaj@cc.bellcore.com _/ _/ Red Bank, NJ 07701 faxmail (908) 758-4177 _/ _/ _/ _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ --=====================_858717807==_ Content-Type: text/plain; charset="us-ascii" Content-Disposition: attachment; filename="SUPPLDS3.TXT" Return-Path: Date: Fri, 7 Mar 97 18:35:03 EST X-Station-Sent-From: joker.bellcore.com X-Sender: kaj@joker.bellcore.com To: kaj2 From: Kaj Tesink Subject: DS3 Supplemental MIB draft proposal Hello, I'd like to propose the following internet-draft for DS3 Supplemental MIB. It has been derived from rfc1407 DS3 MIB, rfcdraft DS3 MIB and rfcdraft DS1 Supplemental MIB (thanks to authors T. Cox, K. Tesink, M. Ahmed, D. Fowler and M. Greene for paving the way). The style is more in line with the standard DS3 and SONET rfc MIBs. The draft reflects the following the major design decisions where it differs from the referenced MIBs. 1. I did not provide MIB objects for supporting resetting various tables/counters. This is because it can be down at the NMS side on the host. The advantage is that the switch then never loses any historical data on the switch side and we can get the desired functionality from the host nms side. This can be debated and if need be I can add objects to reset/default each of the tables. 2. I defined the Near End (NE) and Farr End (FE) objects in one set of tables. This is two make it easier on the implementor, who then needs to support only on set of NMS functions and action routines. It also decreases the code size and simplifies the maintainability. In the case of the original specification I presume it made more sense to separate the two in separate tables because NE is mandatory and FE is optional. Here everything is optional. In addition to ANSI T1.231-1993 counters, I have also included support for counters at PLCP, ADM, and TC layers as needed by other Bellcore General Requirements. I hope that we can consider this draft MIB ground zero and work out way up by satisfying most people's needs. I look forward to hearing comments from other people. Thanks, (RUMI) (c). Network Working Group R. Gonda INTERNET-DRAFT Cascade Communincations Corporation October 1996 Definitions of Supplemental Managed Objects for the DS3/E3 Interface Type Thu Oct 17 14:05:52 EDT 1996 draft-ietf-trunkmib-ds3SuppMIB-00.txt Rumi Sheryar Gonda (editor) Cascade Communication Corporation gonda@casc.com Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Abstract This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes supplemental objects used for managing DS3 and E3 interfaces. This document is a companion document with Definitions of Managed Objects for the DS3/E3 MIB rfc1407 [6], DS3/E3 Draft MIB rfcTBD [14], DS1/E1/DS2/E2 Supplemental MIB rfcTBD [15], and ATM-MIB rfc1695 [16]. This MIB is designed to provide support for ANSI T1.231-1993 standard and other DS3 related information. This MIB's support is optional. Expires April 1997 [Page 1] INTERNET-DRAFT Supplemental DS3/E3 MIB October 1996 This memo specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions. This memo does not specify a standard for the Internet community. This document supplements RFC 1407. Object Definitions DS3SUPPMIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Gauge32 FROM SNMPv2-SMI --NOTIFICATION-TYPE FROM SNMPv2-SMI TruthValue FROM SNMPv2-TC --DisplayString, TimeStamp FROM SNMPv2-TC --MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF InterfaceIndex, ifIndex FROM IF-MIB cascadepm FROM CASCADE-MIB; ds3SuppMIB MODULE-IDENTITY LAST-UPDATED "9610170552Z" -- October 17, 1996 ORGANIZATION "Cascade Communications Corporation" --ORGANIZATION "IETF Trunk MIB Working Group, maybe" CONTACT-INFO " Cascade Communications Corporation Postal: Cascade Communications Corporation 5 Carlise Road Westfard, MA 01886 Tel: +1 508 692 2600 E-mail: support@casc.com WEB: http://www.casc.com" DESCRIPTION "The MIB module that describes DS3 and E3 interfaces supplemental objects. This document supplements RFC 1407 and DS3/E3 Draft MIB rfcTBD [14]. This MIB is optional and provides management support for ANSI T1.231-1993 and RFC 1695. noSuchObject will be returned if no data is available. The objects defined in this MIB module were identified by examining ANSI T1.231-1993 and identifying functionality that was not specified in the standard DS3-MIB. In addition, the Bellcore GR-820-CORE document was consulted, specifically to determine the conformance statements. Expires April 1997 [Page 2] INTERNET-DRAFT Supplemental DS3/E3 MIB October 1996 Also defined in this MIB module are objects defined by ATM MIB rfc1695, Bellcore TR-TSV-000773, Bellcore TR-NWT-001112, and ANSI T1E1.2/94-002R1 specifications. Implementing this MIB is optional in a managed device that has these types of interfaces because of the additional processing and storage capabilities that are required. The management functions described in this memo are particularly appropriate for 'mediation devices' associated with managed device. (See ANSI T1.231-1993.)" ::= { cascadepm 2 } --::= { experimental 3001 } -- Should be replaced with: --::= { ds3 14 } -- -- -- The Supplemental DS3/E3 Group -- Implementation of this group is optional for all systems that -- attach to a DS3/E3 Interface. -- -- The Supplemental DS3/E3 Group consists of seven tables, -- each consisting of Near End and Far End objects: -- DS3/E3 Configuration -- DS3/E3 Current -- DS3/E3 Interval -- DS3/E3 Total -- DS3/E3 Day Interval -- DS3/E3 Current/Interval Threshold -- DS3/E3 Day/Total Threshold -- -- -- The DS3/E3 Configuration Table -- dsx3ConfigTable OBJECT-TYPE SYNTAX SEQUENCE OF Dsx3ConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains additional configuration objects for a DS3 interface." ::= { ds3SuppMIB 1 } dsx3ConfigEntry OBJECT-TYPE SYNTAX Dsx3ConfigEntry Expires April 1997 [Page 3] INTERNET-DRAFT Supplemental DS3/E3 MIB October 1996 MAX-ACCESS not-accessible STATUS current DESCRIPTION "Configuration objects for a particular DS3 interface. This entry augments, or extends, the dsx3ConfigEntry defined in the DS3-MIB." INDEX { ifIndex } ::= { dsx3ConfigTable 1 } Dsx3ConfigEntry ::= SEQUENCE { dsx3ConfigIndex InterfaceIndex, dsx3DayTimeElapsed INTEGER, dsx3ValidDayIntervals INTEGER, dsx3EnableAllTCAs TruthValue, dsx3PLCPAlarmState INTEGER, dsx3TCAlarmState INTEGER, dsx3AICSignal INTEGER, dsx3IdleSignal INTEGER, dsx3PLCPStatus INTEGER, dsx3TCStatus INTEGER, dsx3FEBE INTEGER, dsx3FEAC INTEGER } dsx3ConfigIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "This object is the identifier of a DS3/E3 Interface on a managed device. If there is an ifEntry that is directly associated with this and only this DS3/E3 interface, it should have the same value as ifIndex. Otherwise, number the dsx3LineIndices with an unique identifier following the rules of choosing a number that is greater than ifNumber and numbering the inside interfaces (e.g., equipment side) with even numbers and outside interfaces (e.g, network side) with odd numbers." ::= { dsx3ConfigEntry 1 } dsx3DayTimeElapsed OBJECT-TYPE SYNTAX INTEGER (0..899) MAX-ACCESS read-only STATUS current DESCRIPTION "The number of seconds that have elapsed since the beginning of the near end day error measurement period." ::= { dsx3ConfigEntry 2 } Expires April 1997 [Page 4] INTERNET-DRAFT Supplemental DS3/E3 MIB October 1996 dsx3ValidDayIntervals OBJECT-TYPE SYNTAX INTEGER (0..3) MAX-ACCESS read-only STATUS current DESCRIPTION "The number of previous near end Day intervals for which valid data was collected. The value will be 3 unless the interface was brought online within the last 3 days, in which case the value will be the number of complete 1 day near end intervals since the interface has been online. In the case where the agent is a proxy, it is possible that some intervals are unavailable. In this case, this interval is the maximum interval number for which valid data is available." ::= { dsx3ConfigEntry 3 } dsx3EnableAllTCAs OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This object is used to enable or disable the sending of Threshold Crossing Alerts (TCAs) for the all the threshold on an interface. By default, agents should initialize this object to 'false(2)'" DEFVAL { false } ::= { dsx3ConfigEntry 4 } dsx3PLCPAlarmState OBJECT-TYPE SYNTAX INTEGER (0..65535) MAX-ACCESS read-write STATUS current DESCRIPTION "This object is show current PLCP alarm state." ::= { dsx3ConfigEntry 5 } dsx3TCAlarmState OBJECT-TYPE SYNTAX INTEGER (0..65535) MAX-ACCESS read-write STATUS current DESCRIPTION "This object is show current TC alarm state." ::= { dsx3ConfigEntry 6 } dsx3IdleSignal OBJECT-TYPE SYNTAX INTEGER { dsx3NoIdle(1), dsx3ReceivingIdle(2) Expires April 1997 [Page 5] INTERNET-DRAFT Supplemental DS3/E3 MIB October 1996 } MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the presence Idle signal being received by this DS3 interface." ::= { dsx3ConfigEntry 7 } dsx3AICSignal OBJECT-TYPE SYNTAX INTEGER { dsx3CbitParity(1), dsx3M23orSYNTRAN(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the presence of C-bit application or M23/SYNTRAN application based on the AIC signal being received by this DS3 interface." ::= { dsx3ConfigEntry 8 } dsx3PLCPStatus OBJECT-TYPE SYNTAX INTEGER { dsx3NoPLCPStatus(1), dsx3ReceivingLOF(2), dsx3ReceivingYEL(4), dsx3ReceivingAIS(8), dsx3ReceivingFEBE(16) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the PLCP Status being received by this DS3 interface." ::= { dsx3ConfigEntry 9 } dsx3TCStatus OBJECT-TYPE SYNTAX INTEGER { dsx3NoTCStatus(1), dsx3ReceivingOCD(2), dsx3ReceivingLCD(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the presence FEBE being received by this DS3 interface." ::= { dsx3ConfigEntry 10 } Expires April 1997 [Page 6] INTERNET-DRAFT Supplemental DS3/E3 MIB October 1996 dsx3FEBE OBJECT-TYPE SYNTAX INTEGER { dsx3NoFEBE(1), dsx3ReceivingFEBE(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the presence FEBE being received by this DS3 interface." ::= { dsx3ConfigEntry 11 } dsx3FEAC OBJECT-TYPE SYNTAX INTEGER { dsx3NoFEAC (1), dsx3DS3EquipmentFailure (2), dsx3DS3LOS (4), dsx3DS3OutofFrame (8), dsx3DS3AISreceived (16), dsx3DS3IDLEreceived (32), dsx3DS3NonServiceAffectingEquipFailure (64), dsx3CommonEquipmentFailure (128), dsx3DS3LoopbackReceived (256), dsx3DS1ServiceAffectingEquipmentFailure (512), dsx3DS1NonServiceAffectingEquipFailure (1024), dsx3SingleDS1LOS (2048), dsx3MultipleDS1sLOS (4096) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the presence FEAC being received by this DS3 interface. Non zero INTEGER indicating the current DS3 FEAC status." ::= { dsx3ConfigEntry 12 } -- -- The DS3/E3 Current Table -- dsx3CurrentTable OBJECT-TYPE SYNTAX SEQUENCE OF Dsx3CurrentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The DS3/E3 current table contains various statistics being collected for the current 15 minute interval." Expires April 1997 [Page 7] INTERNET-DRAFT Supplemental DS3/E3 MIB October 1996 ::= { ds3SuppMIB 2 } dsx3CurrentEntry OBJECT-TYPE SYNTAX Dsx3CurrentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the DS3/E3 Current table." INDEX { dsx3CurrentIndex } ::= { dsx3CurrentTable 1 } Dsx3CurrentEntry ::= SEQUENCE { dsx3CurrentIndex InterfaceIndex, dsx3CurrentValidData TruthValue, dsx3CurrentLESAs Gauge32, dsx3CurrentLESBs Gauge32, dsx3CurrentLSESs Gauge32, dsx3CurrentLLOSSs Gauge32, dsx3CurrentPESAPs Gauge32, dsx3CurrentPESBPs Gauge32, dsx3CurrentPESACPs Gauge32, dsx3CurrentPESBCPs Gauge32, dsx3CurrentPAISSs Gauge32, dsx3CurrentPUASCPs Gauge32, dsx3CurrentPFCs Gauge32, dsx3CurrentOCDs Gauge32, dsx3CurrentOCDESs Gauge32, dsx3CurrentLCDs Gauge32, dsx3CurrentLCDESs Gauge32, dsx3CurrentPLCPBIPs Gauge32, dsx3CurrentPLCPLOFs Gauge32, dsx3CurrentPLCPLOFESs Gauge32, dsx3CurrentPLCPYELs Gauge32, dsx3CurrentPLCPYELESs Gauge32, dsx3CurrentPLCPCVs Gauge32, dsx3CurrentPLCPESs Gauge32, dsx3CurrentPLCPSESs Gauge32, dsx3CurrentPLCPSEFs Gauge32, dsx3CurrentPLCPUASs Gauge32, dsx3CurrentPLCPFEBEs Gauge32, dsx3CurrentPLCPFEBEESs Gauge32, dsx3CurrentFEBEs Gauge32, dsx3CurrentPFEValidData TruthValue, dsx3CurrentPFEESACPs Gauge32, dsx3CurrentPFEESBCPs Gauge32, dsx3CurrentPFESASCPs Gauge32, dsx3CurrentPFEFCCPs Gauge32 Expires April 1997 [Page 8] INTERNET-DRAFT Supplemental DS3/E3 MIB October 1996 } dsx3CurrentIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "The index value which uniquely identifies the DS3/E3 interface to which this entry is applicable. The interface identified by a particular value of this index is the same interface as identified by the same value an dsx3LineIndex object instance." ::= { dsx3CurrentEntry 1 } dsx3CurrentValidData OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This variable indicates if there is valid data for the current table." ::= { dsx3CurrentEntry 2 } dsx3CurrentLESAs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of ESA-L encountered by a DS3 interface in the current 15 minute interval." ::= { dsx3CurrentEntry 3 } dsx3CurrentLESBs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of ESB-L encountered by a DS3 interface in the current 15 minute interval." ::= { dsx3CurrentEntry 4 } dsx3CurrentLSESs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION Expires April 1997 [Page 9] INTERNET-DRAFT Supplemental DS3/E3 MIB October 1996 "The counter associated with the number of SES-L encountered by a DS3 interface in the current 15 minute interval." ::= { dsx3CurrentEntry 5 } dsx3CurrentLLOSSs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of LOSS-L encountered by a DS3 interface in the current 15 minute interval." ::= { dsx3CurrentEntry 6 } dsx3CurrentPESAPs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of ESAP-P encountered by a DS3 interface in the current 15 minute interval." ::= { dsx3CurrentEntry 7 } dsx3CurrentPESBPs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of ESBP-P encountered by a DS3 interface in the current 15 minute interval." ::= { dsx3CurrentEntry 8 } dsx3CurrentPESACPs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of ESACP-P encountered by a DS3 interface in the current 15 minute interval." ::= { dsx3CurrentEntry 9 } dsx3CurrentPESBCPs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only Expires April 1997 [Page 10] INTERNET-DRAFT Supplemental DS3/E3 MIB October 1996 STATUS current DESCRIPTION "The counter associated with the number of ESBCP-P encountered by a DS3 interface in the current 15 minute interval." ::= { dsx3CurrentEntry 10 } dsx3CurrentPAISSs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of AISS-P encountered by a DS3 interface in the current 15 minute interval." ::= { dsx3CurrentEntry 11 } dsx3CurrentPUASCPs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of UASCP-P encountered by a DS3 interface in the current 15 minute interval." ::= { dsx3CurrentEntry 12 } dsx3CurrentPFCs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of FC-P encountered by a DS3 interface in the current 15 minute interval." ::= { dsx3CurrentEntry 13 } dsx3CurrentOCDs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of OCD encountered by a DS3 interface in the current 15 minute interval." ::= { dsx3CurrentEntry 14 } dsx3CurrentOCDESs OBJECT-TYPE SYNTAX Gauge32 Expires April 1997 [Page 11] INTERNET-DRAFT Supplemental DS3/E3 MIB October 1996 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of OCD-ES encountered by a DS3 interface in the current 15 minute interval." ::= { dsx3CurrentEntry 15 } dsx3CurrentLCDs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of LCD encountered by a DS3 interface in the current 15 minute interval." ::= { dsx3CurrentEntry 16 } dsx3CurrentLCDESs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of LCD-ES encountered by a DS3 interface in the current 15 minute interval." ::= { dsx3CurrentEntry 17 } dsx3CurrentPLCPBIPs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of PLCP-BIP encountered by a DS3 interface in the current 15 minute interval." ::= { dsx3CurrentEntry 18 } dsx3CurrentPLCPLOFs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of PLCP-LOF encountered by a DS3 interface in the current 15 minute interval." ::= { dsx3CurrentEntry 19 } dsx3CurrentPLCPLOFESs OBJECT-TYPE Expires April 1997 [Page 12] INTERNET-DRAFT Supplemental DS3/E3 MIB October 1996 SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of PLCP-LOF-ES encountered by a DS3 interface in the current 15 minute interval." ::= { dsx3CurrentEntry 20 } dsx3CurrentPLCPYELs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of PLCP-YEL encountered by a DS3 interface in the current 15 minute interval." ::= { dsx3CurrentEntry 21 } dsx3CurrentPLCPYELESs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of PLCP-YEL-ES encountered by a DS3 interface in the current 15 minute interval." ::= { dsx3CurrentEntry 22 } dsx3CurrentPLCPCVs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of PLCP-CV encountered by a DS3 interface in the current 15 minute interval." ::= { dsx3CurrentEntry 23 } dsx3CurrentPLCPESs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of PLCP-ES encountered by a DS3 interface in the current 15 minute interval." ::= { dsx3CurrentEntry 24 } Expires April 1997 [Page 13] INTERNET-DRAFT Supplemental DS3/E3 MIB October 1996 dsx3CurrentPLCPSESs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of PLCP-SES encountered by a DS3 interface in the current 15 minute interval." ::= { dsx3CurrentEntry 25 } dsx3CurrentPLCPSEFs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of PLCP-SEF encountered by a DS3 interface in the current 15 minute interval." ::= { dsx3CurrentEntry 26 } dsx3CurrentPLCPUASs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of PLCP-UAS encountered by a DS3 interface in the current 15 minute interval." ::= { dsx3CurrentEntry 27 } dsx3CurrentPLCPFEBEs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of PLCP-FEBE encountered by a DS3 interface in the current 15 minute interval." ::= { dsx3CurrentEntry 28 } dsx3CurrentPLCPFEBEESs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of PLCP-FEBE-ES encountered by a DS3 interface in the current 15 minute interval." Expires April 1997 [Page 14] INTERNET-DRAFT Supplemental DS3/E3 MIB October 1996 ::= { dsx3CurrentEntry 29 } dsx3CurrentFEBEs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of FEBE encountered by a DS3 interface in the current 15 minute interval." ::= { dsx3CurrentEntry 30 } dsx3CurrentPFEValidData OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This variable indicates if there is valid data for the current table's Far End objects." ::= { dsx3CurrentEntry 31 } dsx3CurrentPFEESACPs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of ESACP-PFE encountered by a DS3 interface in the current 15 minute interval." ::= { dsx3CurrentEntry 32 } dsx3CurrentPFEESBCPs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of ESBCP-PFE encountered by a DS3 interface in the current 15 minute interval." ::= { dsx3CurrentEntry 33 } dsx3CurrentPFESASCPs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of SASCP-PFE encountered by a DS3 interface in the current 15 minute Expires April 1997 [Page 15] INTERNET-DRAFT Supplemental DS3/E3 MIB October 1996 interval." ::= { dsx3CurrentEntry 34 } dsx3CurrentPFEFCCPs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of FCCP-PFE encountered by a DS3 interface in the current 15 minute interval." ::= { dsx3CurrentEntry 35 } -- -- The DS3/E3 Interval Table -- dsx3IntervalTable OBJECT-TYPE SYNTAX SEQUENCE OF Dsx3IntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The DS3/E3 Interval Table contains various statistics collected by each DS3/E3 Interface over the previous 24 hours of operation. The past 24 hours are broken into 96 completed 15 minute intervals." ::= { ds3SuppMIB 3 } dsx3IntervalEntry OBJECT-TYPE SYNTAX Dsx3IntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the DS3/E3 Interval table." INDEX { dsx3IntervalIndex, dsx3IntervalNumber } ::= { dsx3IntervalTable 1 } Dsx3IntervalEntry ::= SEQUENCE { dsx3IntervalIndex InterfaceIndex, dsx3IntervalNumber INTEGER, dsx3IntervalValidData TruthValue, dsx3IntervalLESAs Gauge32, dsx3IntervalLESBs Gauge32, dsx3IntervalLLOSSs Gauge32, dsx3IntervalLSESs Gauge32, dsx3IntervalPESAPs Gauge32, Expires April 1997 [Page 16] INTERNET-DRAFT Supplemental DS3/E3 MIB October 1996 dsx3IntervalPESBPs Gauge32, dsx3IntervalPESACPs Gauge32, dsx3IntervalPESBCPs Gauge32, dsx3IntervalPAISSs Gauge32, dsx3IntervalPUASCPs Gauge32, dsx3IntervalPFCs Gauge32, dsx3IntervalOCDs Gauge32, dsx3IntervalOCDESs Gauge32, dsx3IntervalLCDs Gauge32, dsx3IntervalLCDESs Gauge32, dsx3IntervalPLCPBIPs Gauge32, dsx3IntervalPLCPLOFs Gauge32, dsx3IntervalPLCPLOFESs Gauge32, dsx3IntervalPLCPYELs Gauge32, dsx3IntervalPLCPYELESs Gauge32, dsx3IntervalPLCPCVs Gauge32, dsx3IntervalPLCPESs Gauge32, dsx3IntervalPLCPSESs Gauge32, dsx3IntervalPLCPSEFs Gauge32, dsx3IntervalPLCPUASs Gauge32, dsx3IntervalPLCPFEBEs Gauge32, dsx3IntervalPLCPFEBEESs Gauge32, dsx3IntervalFEBEs Gauge32, dsx3IntervalPFEValidData TruthValue, dsx3IntervalPFEESACPs Gauge32, dsx3IntervalPFEESBCPs Gauge32, dsx3IntervalPFESASCPs Gauge32, dsx3IntervalPFEFCCPs Gauge32 } dsx3IntervalIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "The index value which uniquely identifies the DS3/E3 interface to which this entry is applicable. The interface identified by a particular value of this index is the same interface as identified by the same value an dsx3LineIndex object instance." ::= { dsx3IntervalEntry 1 } dsx3IntervalNumber OBJECT-TYPE SYNTAX INTEGER (1..96) MAX-ACCESS read-only STATUS current DESCRIPTION "A number between 1 and 96, where 1 is the most recently Expires April 1997 [Page 17] INTERNET-DRAFT Supplemental DS3/E3 MIB October 1996 completed 15 minute interval and 96 is the 15 minutes interval completed 23 hours and 45 minutes prior to interval 1." ::= { dsx3IntervalEntry 2 } dsx3IntervalValidData OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This variable indicates if there is valid data for the interval table." ::= { dsx3IntervalEntry 3 } dsx3IntervalLESAs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of ESA-L encountered by a DS3 interface in the individual 15 minute interval." ::= { dsx3IntervalEntry 4 } dsx3IntervalLESBs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of ESB-L encountered by a DS3 interface in the individual 15 minute interval." ::= { dsx3IntervalEntry 5 } dsx3IntervalLLOSSs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of LOSS-L encountered by a DS3 interface in the individual 15 minute interval." ::= { dsx3IntervalEntry 6 } dsx3IntervalLSESs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current Expires April 1997 [Page 18] INTERNET-DRAFT Supplemental DS3/E3 MIB October 1996 DESCRIPTION "The counter associated with the number of SES-L encountered by a DS3 interface in the individual 15 minute interval." _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ _/ _/ _/ Kaj Tesink _/ _/ Bellcore _/ _/ - Emerging Networks vmail (908) 758-5254 _/ _/ 331 Newman Springs Rd. email kaj@cc.bellcore.com _/ _/ Red Bank, NJ 07701 faxmail (908) 758-4177 _/ _/ _/ _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Return-Path: Date: Fri, 7 Mar 97 18:35:06 EST X-Station-Sent-From: joker.bellcore.com X-Sender: kaj@joker.bellcore.com To: kaj2 From: Kaj Tesink Subject: DS3 Supplemental MIB draft proposal/2 ::= { dsx3IntervalEntry 7 } dsx3IntervalPESAPs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of ESAP-P encountered by a DS3 interface in the individual 15 minute interval." ::= { dsx3IntervalEntry 8 } dsx3IntervalPESBPs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of ESBP-P encountered by a DS3 interface in the individual 15 minute interval." ::= { dsx3IntervalEntry 9 } dsx3IntervalPESACPs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of ESACP-P encountered by a DS3 interface in the individual 15 minute interval." ::= { dsx3IntervalEntry 10 } dsx3IntervalPESBCPs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of ESBCP-P encountered by a DS3 interface in the individual 15 minute interval." ::= { dsx3IntervalEntry 11 } dsx3IntervalPAISSs OBJECT-TYPE SYNTAX Gauge32 Expires April 1997 [Page 19] INTERNET-DRAFT Supplemental DS3/E3 MIB October 1996 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of AISS-P encountered by a DS3 interface in the individual 15 minute interval." ::= { dsx3IntervalEntry 12 } dsx3IntervalPUASCPs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of UASCP-P encountered by a DS3 interface in the individual 15 minute interval." ::= { dsx3IntervalEntry 13 } dsx3IntervalPFCs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of FC-P encountered by a DS3 interface in the individual 15 minute interval." ::= { dsx3IntervalEntry 14 } dsx3IntervalOCDs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of OCD encountered by a DS3 interface in the individual 15 minute interval." ::= { dsx3IntervalEntry 15 } dsx3IntervalOCDESs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of OCD-ES encountered by a DS3 interface in the individual 15 minute interval." ::= { dsx3IntervalEntry 16 } Expires April 1997 [Page 20] INTERNET-DRAFT Supplemental DS3/E3 MIB October 1996 dsx3IntervalLCDs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of LCD encountered by a DS3 interface in the individual 15 minute interval." ::= { dsx3IntervalEntry 17 } dsx3IntervalLCDESs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of LCD-ES encountered by a DS3 interface in the individual 15 minute interval." ::= { dsx3IntervalEntry 18 } dsx3IntervalPLCPBIPs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of PLCP-BIP encountered by a DS3 interface in the individual 15 minute interval." ::= { dsx3IntervalEntry 19 } dsx3IntervalPLCPLOFs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of PLCP-LOF encountered by a DS3 interface in the individual 15 minute interval." ::= { dsx3IntervalEntry 20 } dsx3IntervalPLCPLOFESs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of PLCP-LOF-ES encountered by a DS3 interface in the individual 15 minute interval." Expires April 1997 [Page 21] INTERNET-DRAFT Supplemental DS3/E3 MIB October 1996 ::= { dsx3IntervalEntry 21 } dsx3IntervalPLCPYELs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of PLCP-YEL encountered by a DS3 interface in the individual 15 minute interval." ::= { dsx3IntervalEntry 22 } dsx3IntervalPLCPYELESs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of PLCP-YEL-ES encountered by a DS3 interface in the individual 15 minute interval." ::= { dsx3IntervalEntry 23 } dsx3IntervalPLCPCVs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of PLCP-CV encountered by a DS3 interface in the individual 15 minute interval." ::= { dsx3IntervalEntry 24 } dsx3IntervalPLCPESs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of PLCP-ES encountered by a DS3 interface in the individual 15 minute interval." ::= { dsx3IntervalEntry 25 } dsx3IntervalPLCPSESs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of PLCP-SES Expires April 1997 [Page 22] INTERNET-DRAFT Supplemental DS3/E3 MIB October 1996 encountered by a DS3 interface in the individual 15 minute interval." ::= { dsx3IntervalEntry 26 } dsx3IntervalPLCPSEFs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of PLCP-SEF encountered by a DS3 interface in the individual 15 minute interval." ::= { dsx3IntervalEntry 27 } dsx3IntervalPLCPUASs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of PLCP-UAS encountered by a DS3 interface in the individual 15 minute interval." ::= { dsx3IntervalEntry 28 } dsx3IntervalPLCPFEBEs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of PLCP-FEBE encountered by a DS3 interface in the individual 15 minute interval." ::= { dsx3IntervalEntry 29 } dsx3IntervalPLCPFEBEESs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of PLCP-FEBE-ES encountered by a DS3 interface in the individual 15 minute interval." ::= { dsx3IntervalEntry 30 } dsx3IntervalFEBEs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current Expires April 1997 [Page 23] INTERNET-DRAFT Supplemental DS3/E3 MIB October 1996 DESCRIPTION "The counter associated with the number of FEBEs encountered by a DS3 interface in the individual 15 minute interval." ::= { dsx3IntervalEntry 31 } dsx3IntervalPFEValidData OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This variable indicates if there is valid data for the interval table's Far End objects." ::= { dsx3IntervalEntry 32 } dsx3IntervalPFEESACPs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of ESACP-PFE encountered by a DS3 interface in the individual 15 minute interval." ::= { dsx3IntervalEntry 33 } dsx3IntervalPFEESBCPs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of ESBCP-PFE encountered by a DS3 interface in the individual 15 minute interval." ::= { dsx3IntervalEntry 34 } dsx3IntervalPFESASCPs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of SASCP-PFE encountered by a DS3 interface in the individual 15 minute interval." ::= { dsx3IntervalEntry 35 } dsx3IntervalPFEFCCPs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only Expires April 1997 [Page 24] INTERNET-DRAFT Supplemental DS3/E3 MIB October 1996 STATUS current DESCRIPTION "The counter associated with the number of FCCP-PFE encountered by a DS3 interface in the individual 15 minute interval." ::= { dsx3IntervalEntry 36 } -- -- The DS3/E3 Total Table -- dsx3TotalTable OBJECT-TYPE SYNTAX SEQUENCE OF Dsx3TotalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The DS3/E3 Total Table contains the cumulative sum of the various statistics for the 24 hour period preceding the current interval." ::= { ds3SuppMIB 4 } dsx3TotalEntry OBJECT-TYPE SYNTAX Dsx3TotalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the DS3/E3 Total table." INDEX { dsx3TotalIndex } ::= { dsx3TotalTable 1 } Dsx3TotalEntry ::= SEQUENCE { dsx3TotalIndex InterfaceIndex, dsx3TotalValidData TruthValue, dsx3TotalLESAs Gauge32, dsx3TotalLESBs Gauge32, dsx3TotalLLOSSs Gauge32, dsx3TotalLSESs Gauge32, dsx3TotalPESAPs Gauge32, dsx3TotalPESBPs Gauge32, dsx3TotalPESACPs Gauge32, dsx3TotalPESBCPs Gauge32, dsx3TotalPAISSs Gauge32, dsx3TotalPUASCPs Gauge32, dsx3TotalPFCs Gauge32, dsx3TotalOCDs Gauge32, dsx3TotalOCDESs Gauge32, Expires April 1997 [Page 25] INTERNET-DRAFT Supplemental DS3/E3 MIB October 1996 dsx3TotalLCDs Gauge32, dsx3TotalLCDESs Gauge32, dsx3TotalPLCPBIPs Gauge32, dsx3TotalPLCPLOFs Gauge32, dsx3TotalPLCPLOFESs Gauge32, dsx3TotalPLCPYELs Gauge32, dsx3TotalPLCPYELESs Gauge32, dsx3TotalPLCPCVs Gauge32, dsx3TotalPLCPESs Gauge32, dsx3TotalPLCPSESs Gauge32, dsx3TotalPLCPSEFs Gauge32, dsx3TotalPLCPUASs Gauge32, dsx3TotalPLCPFEBEs Gauge32, dsx3TotalPLCPFEBEESs Gauge32, dsx3TotalFEBEs Gauge32, dsx3TotalPFEValidData TruthValue, dsx3TotalPFEESACPs Gauge32, dsx3TotalPFEESBCPs Gauge32, dsx3TotalPFESASCPs Gauge32, dsx3TotalPFEFCCPs Gauge32 } dsx3TotalIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "The index value which uniquely identifies the DS3/E3 interface to which this entry is applicable. The interface identified by a particular value of this index is the same interface as identified by the same value an dsx3LineIndex object instance." ::= { dsx3TotalEntry 1 } dsx3TotalValidData OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This variable indicates if there is valid data for the Total table." ::= { dsx3TotalEntry 2 } dsx3TotalLESAs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION Expires April 1997 [Page 26] INTERNET-DRAFT Supplemental DS3/E3 MIB October 1996 "The counter associated with the number of ESA-L encountered by a DS3 interface in the individual 24 hour interval." ::= { dsx3TotalEntry 3 } dsx3TotalLESBs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of ESB-L encountered by a DS3 interface in the individual 24 hour interval." ::= { dsx3TotalEntry 4 } dsx3TotalLLOSSs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of LOSS-L encountered by a DS3 interface in the individual 24 hour interval." ::= { dsx3TotalEntry 5 } dsx3TotalLSESs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of SES-L encountered by a DS3 interface in the individual 24 hour interval." ::= { dsx3TotalEntry 6 } dsx3TotalPESAPs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of ESAP-P encountered by a DS3 interface in the individual 24 hour interval." ::= { dsx3TotalEntry 7 } dsx3TotalPESBPs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only Expires April 1997 [Page 27] INTERNET-DRAFT Supplemental DS3/E3 MIB October 1996 STATUS current DESCRIPTION "The counter associated with the number of ESBP-P encountered by a DS3 interface in the individual 24 hour interval." ::= { dsx3TotalEntry 8 } dsx3TotalPESACPs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of ESACP-P encountered by a DS3 interface in the individual 24 hour interval." ::= { dsx3TotalEntry 9 } dsx3TotalPESBCPs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of ESBCP-P encountered by a DS3 interface in the individual 24 hour interval." ::= { dsx3TotalEntry 10 } dsx3TotalPAISSs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of AISS-P encountered by a DS3 interface in the individual 24 hour interval." ::= { dsx3TotalEntry 11 } dsx3TotalPUASCPs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of UASCP-P encountered by a DS3 interface in the individual 24 hour interval." ::= { dsx3TotalEntry 12 } dsx3TotalPFCs OBJECT-TYPE Expires April 1997 [Page 28] INTERNET-DRAFT Supplemental DS3/E3 MIB October 1996 SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of FC-P encountered by a DS3 interface in the individual 24 hour interval." ::= { dsx3TotalEntry 13 } dsx3TotalOCDs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of OCD encountered by a DS3 interface in the individual 24 hour interval." ::= { dsx3TotalEntry 14 } dsx3TotalOCDESs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of OCD-ES encountered by a DS3 interface in the individual 24 hour interval." ::= { dsx3TotalEntry 15 } dsx3TotalLCDs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of LCD encountered by a DS3 interface in the interval 24 hour Total." ::= { dsx3TotalEntry 16 } dsx3TotalLCDESs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of LCD-ES encountered by a DS3 interface in the interval 24 hour Total." ::= { dsx3TotalEntry 17 } dsx3TotalPLCPBIPs OBJECT-TYPE Expires April 1997 [Page 29] INTERNET-DRAFT Supplemental DS3/E3 MIB October 1996 SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of PLCP-BIP encountered by a DS3 interface in the individual 24 hour interval." ::= { dsx3TotalEntry 18 } dsx3TotalPLCPLOFs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of PLCP-LOF encountered by a DS3 interface in the individual 24 hour interval." ::= { dsx3TotalEntry 19 } dsx3TotalPLCPLOFESs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of PLCP-LOF-ES encountered by a DS3 interface in the individual 24 hour interval." ::= { dsx3TotalEntry 20 } dsx3TotalPLCPYELs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of PLCP-YEL encountered by a DS3 interface in the individual 24 hour interval." ::= { dsx3TotalEntry 21 } dsx3TotalPLCPYELESs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of PLCP-YEL-ES encountered by a DS3 interface in the individual 24 hour interval." ::= { dsx3TotalEntry 22 } Expires April 1997 [Page 30] INTERNET-DRAFT Supplemental DS3/E3 MIB October 1996 dsx3TotalPLCPCVs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of PLCP-CV encountered by a DS3 interface in the individual 24 hour interval." ::= { dsx3TotalEntry 23 } dsx3TotalPLCPESs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of PLCP-ES encountered by a DS3 interface in the individual 24 hour interval." ::= { dsx3TotalEntry 24 } dsx3TotalPLCPSESs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of PLCP-SES encountered by a DS3 interface in the individual 24 hour interval." ::= { dsx3TotalEntry 25 } dsx3TotalPLCPSEFs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of PLCP-SEF encountered by a DS3 interface in the individual 24 hour interval." ::= { dsx3TotalEntry 26 } dsx3TotalPLCPUASs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of PLCP-UAS encountered by a DS3 interface in the individual 24 hour interval." Expires April 1997 [Page 31] INTERNET-DRAFT Supplemental DS3/E3 MIB October 1996 ::= { dsx3TotalEntry 27 } dsx3TotalPLCPFEBEs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of PLCP-FEBE encountered by a DS3 interface in the individual 24 hour interval." ::= { dsx3TotalEntry 28 } dsx3TotalPLCPFEBEESs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of PLCP-FEBE-ES encountered by a DS3 interface in the individual 24 hour interval." ::= { dsx3TotalEntry 29 } dsx3TotalFEBEs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of FEBEs encountered by a DS3 interface in the individual 24 hour interval." ::= { dsx3TotalEntry 30 } dsx3TotalPFEValidData OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This variable indicates if there is valid data for the Total table's Far End objects." ::= { dsx3TotalEntry 31 } dsx3TotalPFEESACPs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of ESACP-PFE encountered by a DS3 interface in the individual 24 hour Expires April 1997 [Page 32] INTERNET-DRAFT Supplemental DS3/E3 MIB October 1996 interval." ::= { dsx3TotalEntry 32 } dsx3TotalPFEESBCPs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of ESBCP-PFE encountered by a DS3 interface in the individual 24 hour interval." ::= { dsx3TotalEntry 33 } dsx3TotalPFESASCPs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of UASCP-PFE encountered by a DS3 interface in the individual 24 hour interval." ::= { dsx3TotalEntry 34 } dsx3TotalPFEFCCPs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of FCCP-PFE encountered by a DS3 interface in the individual 24 hour interval." ::= { dsx3TotalEntry 35 } -- -- The DS3/E3 Day Interval Table -- dsx3DayIntervalTable OBJECT-TYPE SYNTAX SEQUENCE OF Dsx3DayIntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of up to 3 days DS3 statistic totals for each interface. These totals record up to three days (current, recent, and previous) worth of cummulative statistics. Invalid 15 minute intervals count as 0." ::= { ds3SuppMIB 5 } Expires April 1997 [Page 33] INTERNET-DRAFT Supplemental DS3/E3 MIB October 1996 dsx3DayIntervalEntry OBJECT-TYPE SYNTAX Dsx3DayIntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "One recent day's worth of DS3 statistic totals for an interface." INDEX { dsx3DayIntervalIndex, dsx3DayIntervalNumber } ::= { dsx3DayIntervalTable 1 } Dsx3DayIntervalEntry ::= SEQUENCE { dsx3DayIntervalIndex InterfaceIndex, dsx3DayIntervalNumber INTEGER, dsx3DayIntervalValidData TruthValue, dsx3DayIntervalPESs Gauge32, dsx3DayIntervalPSESs Gauge32, dsx3DayIntervalSEFSs Gauge32, dsx3DayIntervalUASs Gauge32, dsx3DayIntervalLCVs Gauge32, dsx3DayIntervalPCVs Gauge32, dsx3DayIntervalLESs Gauge32, dsx3DayIntervalCCVs Gauge32, dsx3DayIntervalCESs Gauge32, dsx3DayIntervalCSESs Gauge32, dsx3DayIntervalLESAs Gauge32, dsx3DayIntervalLESBs Gauge32, dsx3DayIntervalLLOSSs Gauge32, dsx3DayIntervalLSESs Gauge32, dsx3DayIntervalPESAPs Gauge32, dsx3DayIntervalPESBPs Gauge32, dsx3DayIntervalPESACPs Gauge32, dsx3DayIntervalPESBCPs Gauge32, dsx3DayIntervalPAISSs Gauge32, dsx3DayIntervalPUASCPs Gauge32, dsx3DayIntervalPFCs Gauge32, dsx3DayIntervalOCDs Gauge32, dsx3DayIntervalOCDESs Gauge32, dsx3DayIntervalLCDs Gauge32, dsx3DayIntervalLCDESs Gauge32, dsx3DayIntervalPLCPBIPs Gauge32, dsx3DayIntervalPLCPLOFs Gauge32, dsx3DayIntervalPLCPLOFESs Gauge32, dsx3DayIntervalPLCPYELs Gauge32, dsx3DayIntervalPLCPYELESs Gauge32, dsx3DayIntervalPLCPCVs Gauge32, dsx3DayIntervalPLCPESs Gauge32, dsx3DayIntervalPLCPSEFs Gauge32, Expires April 1997 [Page 34] INTERNET-DRAFT Supplemental DS3/E3 MIB October 1996 dsx3DayIntervalPLCPSESs Gauge32, dsx3DayIntervalPLCPUASs Gauge32, dsx3DayIntervalPLCPFEBEs Gauge32, dsx3DayIntervalPLCPFEBEESs Gauge32, dsx3DayIntervalFEBEs Gauge32, dsx3DayIntervalPFECESs Gauge32, dsx3DayIntervalPFECSESs Gauge32, dsx3DayIntervalPFECCVs Gauge32, dsx3DayIntervalPFEUASs Gauge32, dsx3DayIntervalPFEValidData TruthValue, dsx3DayIntervalPFEESACPs Gauge32, dsx3DayIntervalPFEESBCPs Gauge32, dsx3DayIntervalPFESASCPs Gauge32, dsx3DayIntervalPFEFCCPs Gauge32 } dsx3DayIntervalIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "The index value which uniquely identifies the DS3/E3 interface to which this entry is applicable. The interface identified by a particular value of this index is the same interface as identified by the same value an dsx3LineIndex object instance." ::= { dsx3DayIntervalEntry 1 } dsx3DayIntervalNumber OBJECT-TYPE SYNTAX INTEGER (1..3) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A number between 1 and 3, where 1 is the most recently completed 24 hour interval and 3 is the 24 hour interval completed 48 hours prior to interval 1. These totals record up to three days (current, recent, and previous) worth of cummulative statistics." ::= { dsx3DayIntervalEntry 2 } dsx3DayIntervalValidData OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates if there is valid data for this day interval." DEFVAL { true } ::= { dsx3DayIntervalEntry 3 } Expires April 1997 [Page 35] INTERNET-DRAFT Supplemental DS3/E3 MIB October 1996 dsx3DayIntervalPESs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of ESP-P P-bit Errored Seconds, encountered by a DS3 interface in the individual 24 hour interval." ::= { dsx3DayIntervalEntry 4 } dsx3DayIntervalPSESs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of SESP-P P-bit Severely Errored Seconds, encountered by a DS3 interface in the individual 24 hour interval." ::= { dsx3DayIntervalEntry 5 } dsx3DayIntervalSEFSs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of SAS-P Severely Errored Framing Seconds, encountered by a DS3/E3 interface in the individual 24 hour interval." ::= { dsx3DayIntervalEntry 6 } dsx3DayIntervalUASs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of UASP-P Unavailable Seconds, encountered by a DS3 interface in the individual 24 hour interval." ::= { dsx3DayIntervalEntry 7 } dsx3DayIntervalLCVs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of CV-L Line Coding Violations encountered by a DS3/E3 interface in the individual 24 hour interval." Expires April 1997 [Page 36] INTERNET-DRAFT Supplemental DS3/E3 MIB October 1996 ::= { dsx3DayIntervalEntry 8 } dsx3DayIntervalPCVs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of CV-P P-bit Coding Violations, encountered by a DS3 interface in the individual 24 hour interval." ::= { dsx3DayIntervalEntry 9 } dsx3DayIntervalLESs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of ES-L Line Errored Seconds (BPVs or illegal zero sequences) encountered by a DS3/E3 interface in the individual 24 hour interval." ::= { dsx3DayIntervalEntry 10 } dsx3DayIntervalCCVs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of CVCP-P C-bit Coding Violations encountered by a DS3 interface in the individual 24 hour interval." ::= { dsx3DayIntervalEntry 11 } dsx3DayIntervalCESs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of ESCP-P C-bit Errored Seconds encountered by a DS3 interface in the individual 24 hour interval." ::= { dsx3DayIntervalEntry 12 } dsx3DayIntervalCSESs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION Expires April 1997 [Page 37] INTERNET-DRAFT Supplemental DS3/E3 MIB October 1996 "The counter associated with the number of SESCP-P C-bit Severely Errored Seconds encountered by a DS3 interface in the individual 24 hour interval." ::= { dsx3DayIntervalEntry 13 } dsx3DayIntervalLESAs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of ESA-L encountered by a DS3 interface in the individual 24 hour interval." ::= { dsx3DayIntervalEntry 14 } dsx3DayIntervalLESBs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of ESB-L encountered by a DS3 interface in the individual 24 hour interval." ::= { dsx3DayIntervalEntry 15 } dsx3DayIntervalLLOSSs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of LOSS-L encountered by a DS3 interface in the individual 24 hour interval." ::= { dsx3DayIntervalEntry 16 } dsx3DayIntervalLSESs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of SES-L encountered by a DS3 interface in the individual 24 hour interval." ::= { dsx3DayIntervalEntry 17 } dsx3DayIntervalPESAPs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only Expires April 1997 [Page 38] INTERNET-DRAFT Supplemental DS3/E3 MIB October 1996 STATUS current DESCRIPTION "The counter associated with the number of ESAP-P encountered by a DS3 interface in the individual 24 hour interval." ::= { dsx3DayIntervalEntry 18 } dsx3DayIntervalPESBPs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of ESBP-P encountered by a DS3 interface in the individual 24 hour interval." ::= { dsx3DayIntervalEntry 19 } dsx3DayIntervalPESACPs OBJECT-TYPE SYNTAX Gauge32 _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ _/ _/ _/ Kaj Tesink _/ _/ Bellcore _/ _/ - Emerging Networks vmail (908) 758-5254 _/ _/ 331 Newman Springs Rd. email kaj@cc.bellcore.com _/ _/ Red Bank, NJ 07701 faxmail (908) 758-4177 _/ _/ _/ _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Return-Path: Date: Fri, 7 Mar 97 18:35:08 EST X-Station-Sent-From: joker.bellcore.com X-Sender: kaj@joker.bellcore.com To: kaj2 From: Kaj Tesink Subject: DS3 Supplemental MIB draft proposal/3 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of ESACP-P encountered by a DS3 interface in the individual 24 hour interval." ::= { dsx3DayIntervalEntry 20 } dsx3DayIntervalPESBCPs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of ESBCP-P encountered by a DS3 interface in the individual 24 hour interval." ::= { dsx3DayIntervalEntry 21 } dsx3DayIntervalPAISSs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of AISS-P encountered by a DS3 interface in the individual 24 hour interval." ::= { dsx3DayIntervalEntry 22 } dsx3DayIntervalPUASCPs OBJECT-TYPE Expires April 1997 [Page 39] INTERNET-DRAFT Supplemental DS3/E3 MIB October 1996 SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of UASCP-P encountered by a DS3 interface in the individual 24 hour interval." ::= { dsx3DayIntervalEntry 23 } dsx3DayIntervalPFCs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of FC-P encountered by a DS3 interface in the individual 24 hour interval." ::= { dsx3DayIntervalEntry 24 } dsx3DayIntervalOCDs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of OCD encountered by a DS3 interface in the individual 24 hour interval." ::= { dsx3DayIntervalEntry 25 } dsx3DayIntervalOCDESs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of OCD-ES encountered by a DS3 interface in the individual 24 hour interval." ::= { dsx3DayIntervalEntry 26 } dsx3DayIntervalLCDESs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of LCD-ES encountered by a DS3 interface in the interval 24 hour interval." ::= { dsx3DayIntervalEntry 27 } Expires April 1997 [Page 40] INTERNET-DRAFT Supplemental DS3/E3 MIB October 1996 dsx3DayIntervalLCDs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of LCD encountered by a DS3 interface in the interval 24 hour interval." ::= { dsx3DayIntervalEntry 28 } dsx3DayIntervalPLCPBIPs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of PLCP-BIP encountered by a DS3 interface in the individual 24 hour interval." ::= { dsx3DayIntervalEntry 29 } dsx3DayIntervalPLCPLOFs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of PLCP-LOF encountered by a DS3 interface in the individual 24 hour interval." ::= { dsx3DayIntervalEntry 30 } dsx3DayIntervalPLCPLOFESs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of PLCP-LOF-ES encountered by a DS3 interface in the individual 24 hour interval." ::= { dsx3DayIntervalEntry 31 } dsx3DayIntervalPLCPYELs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of PLCP-YEL encountered by a DS3 interface in the individual 24 hour interval." ::= { dsx3DayIntervalEntry 32 } Expires April 1997 [Page 41] INTERNET-DRAFT Supplemental DS3/E3 MIB October 1996 dsx3DayIntervalPLCPYELESs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of PLCP-YEL-ES encountered by a DS3 interface in the individual 24 hour interval." ::= { dsx3DayIntervalEntry 33 } dsx3DayIntervalPLCPCVs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of PLCP-CV encountered by a DS3 interface in the individual 24 hour interval." ::= { dsx3DayIntervalEntry 34 } dsx3DayIntervalPLCPESs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of PLCP-ES encountered by a DS3 interface in the individual 24 hour interval." ::= { dsx3DayIntervalEntry 35 } dsx3DayIntervalPLCPSESs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of PLCP-SES encountered by a DS3 interface in the individual 24 hour interval." ::= { dsx3DayIntervalEntry 36 } dsx3DayIntervalPLCPSEFs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of PLCP-SEF encountered by a DS3 interface in the individual 24 hour interval." Expires April 1997 [Page 42] INTERNET-DRAFT Supplemental DS3/E3 MIB October 1996 ::= { dsx3DayIntervalEntry 37 } dsx3DayIntervalPLCPUASs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of PLCP-UAS encountered by a DS3 interface in the individual 24 hour interval." ::= { dsx3DayIntervalEntry 38 } dsx3DayIntervalPLCPFEBEs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of PLCP-FEBE encountered by a DS3 interface in the individual 24 hour interval." ::= { dsx3DayIntervalEntry 39 } dsx3DayIntervalPLCPFEBEESs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of PLCP-FEBE-ES encountered by a DS3 interface in the individual 24 hour interval." ::= { dsx3DayIntervalEntry 40 } dsx3DayIntervalFEBEs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of FEBEs encountered by a DS3 interface in the individual 24 hour interval." ::= { dsx3DayIntervalEntry 41 } dsx3DayIntervalPFECESs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of ESCP-PFE C-bit Expires April 1997 [Page 43] INTERNET-DRAFT Supplemental DS3/E3 MIB October 1996 Errored Seconds encountered by a DS3 interface in the individual 24 hour interval." ::= { dsx3DayIntervalEntry 42 } dsx3DayIntervalPFECSESs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of SESCP-PFE C-bit Severely Errored Seconds encountered by a DS3 interface in the individual 24 hour interval." ::= { dsx3DayIntervalEntry 43 } dsx3DayIntervalPFECCVs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of CVCP-PFE C-bit Coding Violations encountered by a DS3 interface in the individual 24 hour interval." ::= { dsx3DayIntervalEntry 44 } dsx3DayIntervalPFEUASs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of UASCP-PFE Unavailable Seconds, encountered by a DS3 interface in the individual 24 hour interval." ::= { dsx3DayIntervalEntry 45 } dsx3DayIntervalPFEValidData OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This variable indicates if there is valid data for the Day Interval table's Far End objects." DEFVAL { true } ::= { dsx3DayIntervalEntry 46 } dsx3DayIntervalPFEESACPs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current Expires April 1997 [Page 44] INTERNET-DRAFT Supplemental DS3/E3 MIB October 1996 DESCRIPTION "The counter associated with the number of ESACP-PFE encountered by a DS3 interface in the individual 24 hour interval." ::= { dsx3DayIntervalEntry 47 } dsx3DayIntervalPFEESBCPs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of ESBCP-PFE encountered by a DS3 interface in the individual 24 hour interval." ::= { dsx3DayIntervalEntry 48 } dsx3DayIntervalPFESASCPs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of SASCP-PFE encountered by a DS3 interface in the individual 24 hour interval." ::= { dsx3DayIntervalEntry 49 } dsx3DayIntervalPFEFCCPs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of FCCP-PFE encountered by a DS3 interface in the individual 24 hour interval." ::= { dsx3DayIntervalEntry 50 } -- -- The Current/Interval 15 Minute Interval Threshold Table -- dsx3CurrentThresholdTable OBJECT-TYPE SYNTAX SEQUENCE OF Dsx3CurrentThresholdEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Thresholds on parameters for the current 15 minute Expires April 1997 [Page 45] INTERNET-DRAFT Supplemental DS3/E3 MIB October 1996 interval per interface." ::= { ds3SuppMIB 6 } dsx3CurrentThresholdEntry OBJECT-TYPE SYNTAX Dsx3CurrentThresholdEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Thresholds for the current 15 minute interval for a particular interface. If thesholding is not supported on a particular parameter, the error 'noSuchObject' should be returned." INDEX { dsx3CurrentThresholdIndex } ::= { dsx3CurrentThresholdTable 1 } Dsx3CurrentThresholdEntry ::= SEQUENCE { dsx3CurrentThresholdIndex InterfaceIndex, dsx3CurrentThresholdLCVs Gauge32, dsx3CurrentThresholdLESs Gauge32, dsx3CurrentThresholdLSESs Gauge32, dsx3CurrentThresholdPCVs Gauge32, dsx3CurrentThresholdPESs Gauge32, dsx3CurrentThresholdPSESs Gauge32, dsx3CurrentThresholdPSASs Gauge32, dsx3CurrentThresholdPUASs Gauge32, dsx3CurrentThresholdPCVCPs Gauge32, dsx3CurrentThresholdPESCPs Gauge32, dsx3CurrentThresholdPSESCPs Gauge32, dsx3CurrentThresholdPSASCPs Gauge32, dsx3CurrentThresholdPUASCPs Gauge32, dsx3CurrentThresholdESxs Gauge32, dsx3CurrentThresholdPFECVCPs Gauge32, dsx3CurrentThresholdPFEESCPs Gauge32, dsx3CurrentThresholdPFESESCPs Gauge32, dsx3CurrentThresholdPFESASCPs Gauge32, dsx3CurrentThresholdPFEUASCPs Gauge32 } dsx3CurrentThresholdIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The index value which uniquely identifies the DS3/E3 interface to which this entry is applicable. The interface identified by a particular value of this index is the same interface as identified by the same value an dsx3LineIndex object instance." Expires April 1997 [Page 46] INTERNET-DRAFT Supplemental DS3/E3 MIB October 1996 ::= { dsx3CurrentThresholdEntry 1 } dsx3CurrentThresholdLCVs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-write STATUS current DESCRIPTION "A threshold on the number of Line Code Violations encountered by a DS3 interface in the current 15 minute interval." DEFVAL { 13296 } ::= { dsx3CurrentThresholdEntry 2 } dsx3CurrentThresholdLESs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-write STATUS current DESCRIPTION "A threshold on the number of Line Errored Seconds encountered by a DS3 interface in the current 15 minute interval." DEFVAL { 65 } ::= { dsx3CurrentThresholdEntry 3 } dsx3CurrentThresholdLSESs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-write STATUS current DESCRIPTION "A threshold on the number of Line Severly Errored Seconds encountered by a DS3 interface in the current 15 minute interval." DEFVAL { 10 } ::= { dsx3CurrentThresholdEntry 4 } dsx3CurrentThresholdPCVs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-write STATUS current DESCRIPTION "A threshold on the number of Path Coding Violations encountered by a DS3 interface in the current 15 minute interval." DEFVAL { 13296 } ::= { dsx3CurrentThresholdEntry 5 } dsx3CurrentThresholdPESs OBJECT-TYPE SYNTAX Gauge32 Expires April 1997 [Page 47] INTERNET-DRAFT Supplemental DS3/E3 MIB October 1996 MAX-ACCESS read-write STATUS current DESCRIPTION "A threshold on the number of Path Errored Seconds encountered by a DS3 interface in the current 15 minute interval." DEFVAL { 65 } ::= { dsx3CurrentThresholdEntry 6 } dsx3CurrentThresholdPSESs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-write STATUS current DESCRIPTION "A threshold on the number of Path Severely Errored Seconds encountered by a DS3 interface in the current 15 minute interval." DEFVAL { 10 } ::= { dsx3CurrentThresholdEntry 7 } dsx3CurrentThresholdPSASs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-write STATUS current DESCRIPTION "A threshold on the number of Path Severely Errored Framing/Alarm Indication Signal Seconds encountered by a DS3 interface in the current 15 minute interval." DEFVAL { 2 } ::= { dsx3CurrentThresholdEntry 8 } dsx3CurrentThresholdPUASs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-write STATUS current DESCRIPTION "A threshold on the number of Path Unavailable Seconds encountered by a DS3 interface in the current 15 minute interval." DEFVAL { 10 } ::= { dsx3CurrentThresholdEntry 9 } dsx3CurrentThresholdPCVCPs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-write STATUS current DESCRIPTION "A threshold on the number of CP-bit Path Coding Expires April 1997 [Page 48] INTERNET-DRAFT Supplemental DS3/E3 MIB October 1996 Violations encountered by a DS3 interface in the current 15 minute interval." DEFVAL { 13296 } ::= { dsx3CurrentThresholdEntry 10 } dsx3CurrentThresholdPESCPs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-write STATUS current DESCRIPTION "A threshold on the number of CP-bit Path Errored Seconds encountered by a DS3 interface in the current 15 minute interval." DEFVAL { 65 } ::= { dsx3CurrentThresholdEntry 11 } dsx3CurrentThresholdPSESCPs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-write STATUS current DESCRIPTION "A threshold on the number of CP-bit Path Severely Errored Seconds encountered by a DS3 interface in the current 15 minute interval." DEFVAL { 10 } ::= { dsx3CurrentThresholdEntry 12 } dsx3CurrentThresholdPSASCPs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-write STATUS current DESCRIPTION "A threshold on the number of CP-bit Path Severely Errored Framing/Alarm Indication Signal Seconds encountered by a DS3 interface in the current 15 minute interval." DEFVAL { 2 } ::= { dsx3CurrentThresholdEntry 13 } dsx3CurrentThresholdPUASCPs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-write STATUS current DESCRIPTION "A threshold on the number of CP-bit Path Unavailable Seconds encountered by a DS3 interface in the current 15 minute interval." DEFVAL { 10 } ::= { dsx3CurrentThresholdEntry 14 } Expires April 1997 [Page 49] INTERNET-DRAFT Supplemental DS3/E3 MIB October 1996 dsx3CurrentThresholdESxs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-write STATUS current DESCRIPTION "A threshold on x number of defects in Errored Seconds encountered by a DS3 interface in the current 15 minute interval." DEFVAL { 44 } ::= { dsx3CurrentThresholdEntry 15 } dsx3CurrentThresholdPFECVCPs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-write STATUS current DESCRIPTION "A threshold on the number of CP-bit Path Far End Coding Violations encountered by a DS3 interface in the current 15 minute interval." DEFVAL { 13296 } ::= { dsx3CurrentThresholdEntry 16 } dsx3CurrentThresholdPFEESCPs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-write STATUS current DESCRIPTION "A threshold on the number of CP-bit Path Far End Errored Seconds encountered by a DS3 interface in the current 15 minute interval." DEFVAL { 65 } ::= { dsx3CurrentThresholdEntry 17 } dsx3CurrentThresholdPFESESCPs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-write STATUS current DESCRIPTION "A threshold on the number of CP-bit Path Far End Severely Errored Seconds encountered by a DS3 interface in the current 15 minute interval." DEFVAL { 10 } ::= { dsx3CurrentThresholdEntry 18 } dsx3CurrentThresholdPFESASCPs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-write STATUS current Expires April 1997 [Page 50] INTERNET-DRAFT Supplemental DS3/E3 MIB October 1996 DESCRIPTION "A threshold on the number of CP-bit Path Far End Severely Errored Framing/Alarm Indication Signal Seconds encountered by a DS3 interface in the current 15 minute interval." DEFVAL { 2 } ::= { dsx3CurrentThresholdEntry 19 } dsx3CurrentThresholdPFEUASCPs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-write STATUS current DESCRIPTION "A threshold on the number of CP-bit Path Far End Unavailable Seconds encountered by a DS3 interface in the current 15 minute interval." DEFVAL { 10 } ::= { dsx3CurrentThresholdEntry 20 } -- -- The DS3/E3 24 Hour Day/Total Interval Threshold Table -- dsx3DayThresholdTable OBJECT-TYPE SYNTAX SEQUENCE OF Dsx3DayThresholdEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Thresholds on parameters for the current 24 hour interval per interface." ::= { ds3SuppMIB 7 } dsx3DayThresholdEntry OBJECT-TYPE SYNTAX Dsx3DayThresholdEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Thresholds on parameters for the current 24 hour interval for a particular interface. If thesholding is not supported on a particular parameter, the error 'noSuchObject' should be returned." INDEX { dsx3DayThresholdIndex } ::= { dsx3DayThresholdTable 1 } Dsx3DayThresholdEntry ::= SEQUENCE { dsx3DayThresholdIndex InterfaceIndex, Expires April 1997 [Page 51] INTERNET-DRAFT Supplemental DS3/E3 MIB October 1996 dsx3DayThresholdLCVs Gauge32, dsx3DayThresholdLESs Gauge32, dsx3DayThresholdLSESs Gauge32, dsx3DayThresholdPCVs Gauge32, dsx3DayThresholdPESs Gauge32, dsx3DayThresholdPSESs Gauge32, dsx3DayThresholdPSASs Gauge32, dsx3DayThresholdPUASs Gauge32, dsx3DayThresholdPCVCPs Gauge32, dsx3DayThresholdPESCPs Gauge32, dsx3DayThresholdPSESCPs Gauge32, dsx3DayThresholdPSASCPs Gauge32, dsx3DayThresholdPUASCPs Gauge32, dsx3DayThresholdESxs Gauge32, dsx3DayThresholdPFECVCPs Gauge32, dsx3DayThresholdPFEESCPs Gauge32, dsx3DayThresholdPFESESCPs Gauge32, dsx3DayThresholdPFESASCPs Gauge32, dsx3DayThresholdPFEUASCPs Gauge32 } dsx3DayThresholdIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The index value which uniquely identifies the DS3/E3 interface to which this entry is applicable. The interface identified by a particular value of this index is the same interface as identified by the same value an dsx3LineIndex object instance." ::= { dsx3DayThresholdEntry 1 } dsx3DayThresholdLCVs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-write STATUS current DESCRIPTION "A threshold on the number of Line Code Violations encountered by a DS3 interface in the current 24 hour interval." DEFVAL { 132960 } ::= { dsx3DayThresholdEntry 2 } dsx3DayThresholdLESs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-write STATUS current DESCRIPTION Expires April 1997 [Page 52] INTERNET-DRAFT Supplemental DS3/E3 MIB October 1996 "A threshold on the number of Line Errored Seconds encountered by a DS3 interface in the current 24 hour interval." DEFVAL { 648 } ::= { dsx3DayThresholdEntry 3 } dsx3DayThresholdLSESs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-write STATUS current DESCRIPTION "A threshold on the number of Line Severly Errored Seconds encountered by a DS3 interface in the current 24 hour interval." DEFVAL { 100 } ::= { dsx3DayThresholdEntry 4 } dsx3DayThresholdPCVs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-write STATUS current DESCRIPTION "A threshold on the number of Path Coding Violations encountered by a DS3 interface in the current 24 hour interval." DEFVAL { 132960 } ::= { dsx3DayThresholdEntry 5 } dsx3DayThresholdPESs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-write STATUS current DESCRIPTION "A threshold on the number of Path Errored Seconds encountered by a DS3 interface in the current 24 hour interval." DEFVAL { 648 } ::= { dsx3DayThresholdEntry 6 } dsx3DayThresholdPSESs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-write STATUS current DESCRIPTION "A threshold on the number of Path Severely Errored Seconds encountered by a DS3 interface in the current 24 hour interval." Expires April 1997 [Page 53] INTERNET-DRAFT Supplemental DS3/E3 MIB October 1996 DEFVAL { 100 } ::= { dsx3DayThresholdEntry 7 } dsx3DayThresholdPSASs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-write STATUS current DESCRIPTION "A threshold on the number of Path Severely Errored Framing/Alarm Indication Signal Seconds encountered by a DS3 interface in the current 24 hour interval." DEFVAL { 17 } ::= { dsx3DayThresholdEntry 8 } dsx3DayThresholdPUASs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-write STATUS current DESCRIPTION "A threshold on the number of Path Unavailable Seconds encountered by a DS3 interface in the current 24 hour interval." DEFVAL { 10 } ::= { dsx3DayThresholdEntry 9 } dsx3DayThresholdPCVCPs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-write STATUS current DESCRIPTION "A threshold on the number of CP-bit Path Coding Violations encountered by a DS3 interface in the current 24 hour interval." DEFVAL { 132960 } ::= { dsx3DayThresholdEntry 10 } dsx3DayThresholdPESCPs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-write STATUS current DESCRIPTION "A threshold on the number of CP-bit Path Errored Seconds encountered by a DS3 interface in the current 24 hour interval." DEFVAL { 648 } ::= { dsx3DayThresholdEntry 11 } dsx3DayThresholdPSESCPs OBJECT-TYPE Expires April 1997 [Page 54] INTERNET-DRAFT Supplemental DS3/E3 MIB October 1996 SYNTAX Gauge32 MAX-ACCESS read-write STATUS current DESCRIPTION "A threshold on the number of CP-bit Path Severely Errored Seconds encountered by a DS3 interface in the current 24 hour interval." DEFVAL { 100 } ::= { dsx3DayThresholdEntry 12 } dsx3DayThresholdPSASCPs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-write STATUS current DESCRIPTION "A threshold on the number of CP-bit Path Severely Errored Framing/Alarm Indication Signal Seconds encountered by a DS3 interface in the current 24 hour interval." DEFVAL { 17 } ::= { dsx3DayThresholdEntry 13 } dsx3DayThresholdPUASCPs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-write STATUS current DESCRIPTION "A threshold on the number of CP-bit Path Unavailable Seconds encountered by a DS3 interface in the current 24 hour interval." DEFVAL { 10 } ::= { dsx3DayThresholdEntry 14 } dsx3DayThresholdESxs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-write STATUS current DESCRIPTION "A threshold on x number of defects in Errored Seconds encountered by a DS3 interface in the current 24 hour interval." DEFVAL { 44 } ::= { dsx3DayThresholdEntry 15 } dsx3DayThresholdPFECVCPs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-write STATUS current DESCRIPTION Expires April 1997 [Page 55] INTERNET-DRAFT Supplemental DS3/E3 MIB October 1996 "A threshold on the number of CP-bit Path Far End Coding Violations encountered by a DS3 interface in the current 24 hour interval." DEFVAL { 132960 } ::= { dsx3DayThresholdEntry 16 } dsx3DayThresholdPFEESCPs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-write STATUS current DESCRIPTION "A threshold on the number of CP-bit Path Far End Errored Seconds encountered by a DS3 interface in the current 24 hour interval." DEFVAL { 648 } ::= { dsx3DayThresholdEntry 17 } dsx3DayThresholdPFESESCPs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-write STATUS current DESCRIPTION "A threshold on the number of CP-bit Path Far End Severely Errored Seconds encountered by a DS3 interface in the current 24 hour interval." DEFVAL { 100 } ::= { dsx3DayThresholdEntry 18 } dsx3DayThresholdPFESASCPs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-write STATUS current DESCRIPTION "A threshold on the number of CP-bit Path Far End Severely Errored Framing/Alarm Indication Signal Seconds encountered by a DS3 interface in the current 24 hour interval." DEFVAL { 17 } ::= { dsx3DayThresholdEntry 19 } dsx3DayThresholdPFEUASCPs OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-write STATUS current DESCRIPTION "A threshold on the number of CP-bit Path Far End Unavailable Seconds encountered by a DS3 interface in the current 24 hour interval." Expires April 1997 [Page 56] INTERNET-DRAFT Supplemental DS3/E3 MIB October 1996 DEFVAL { 10 } ::= { dsx3DayThresholdEntry 20 } END Acknowledgments This document was produced by the Trunk MIB Working Group References [1] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1902, January 1996. [2] McCloghrie, K., and M. Rose, Editors, "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", STD 17, RFC 1213, Hughes LAN Systems, Performance Systems International, March 1991. [3] Case, J., Fedor, M., Schoffstall, M., and J. Davin. " A Simple Network Management Protocol (SNMP)", STD 15, RFC 1157, SNMP Research, Performance Systems International, MIT Lab for Com- puter Science, May 1990. [4] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, January 1996. [5] McCloghrie, K. and F. Kastenholz, "Evolution of the Interfaces Group of MIB-II", draft-ietf-ifmib-mib-03.txt, Cisco, FTP Software, January 1994. [6] Cox, T., and Tesink, K., "Definitions of Managed Objects for the DS3 and E3 Interface Types", rfc1407.txt, Bell Communica- tions Research, January 1993. [7] Brown, T., and Tesink, K., "Definitions of Managed Objects for the SONET/SDH Interface Type", RFC1595, Bell Communications Research, March 1994. [8] American National Standard for telecommunications - digital hierarchy - electrical interfaces, ANSI T1.102- 1987. [9] American National Standard for telecommunications - digital hierarchy - formats specification, ANSI T1.107- 1988. Expires April 1997 [Page 57] INTERNET-DRAFT Supplemental DS3/E3 MIB October 1996 [9a] ANSI T1.107a-1990. [10] American National Standard for telecommunications - Carrier-to- Customer Installation - DS3 Metallic Interface, ANSI T1.404- 1989. [11] American National Standard for Telecommunications -- Layer 1 In-Service Digital Transmission Performance Monitoring T1.231, Sept 1993. [12] CCITT - Digital Multiplex Equipment Operating at the Third Order Bit Rate of 34 368 Kbit/s and the Forth Order Bit Rate of 139 264 Kbit/s and Using Positive Justification, G.751 [13] European Telecommunications Standards Institute -- ETS "34M" -- Metropolitan Area Network Physical Convergence Layer Procedure for 34.368 Megabits per Second, T/NA(91)18, May 1991. [14] Fowler D., "Definitions of Managed Objects for the DS3 and E1 Interface Types", draft-ietf-trunkmib-ds3-mib-03.txt, Newbridge Networks Corporation, September 1996. [15] Greene, M., "Definitions for DS1, E1, DS2, and E2 interfaces that supplement those in the standard DS1-MIB", draft-ietf- trunkmib-ds1-supp-mib-01.txt, Ascom Nexion, May 1996. [16] Ahmed, M., and Tesink, K., "Definitions of Managed Objects for ATM Management Version 8.0 using SMIv2", rfc1695.txt, Bell Com- munications Research, August 1994. Security Considerations Security issues are not discussed in this memo. Author's Address Rumi Sheryar Gonda Cascade Communication Corporation 5 Carlise Road Westfard, MA 01886 Phone: (508) 692-1372 EMail: gonda@casc.com Expires April 1997 [Page 58] _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ _/ _/ _/ Kaj Tesink _/ _/ Bellcore _/ _/ - Emerging Networks vmail (908) 758-5254 _/ _/ 331 Newman Springs Rd. email kaj@cc.bellcore.com _/ _/ Red Bank, NJ 07701 faxmail (908) 758-4177 _/ _/ _/ _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ --=====================_858717807==_ Content-Type: text/plain; charset="us-ascii" _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ _/ _/ _/ Kaj Tesink _/ _/ Bellcore _/ _/ - Broadband Data Services & Consulting vmail (908) 758-5254 _/ _/ 331 Newman Springs Rd. email kaj@cc.bellcore.com _/ _/ Red Bank, NJ 07701 faxmail (908) 758-4177 _/ _/ _/ _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ --=====================_858717807==_--   Received: from cnri by ietf.org id aa08557; 19 Mar 97 10:49 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa13063; 19 Mar 97 10:49 EST Received: from celeste.switch.ch (celeste.switch.ch [130.59.4.16]) by thumper.bellcore.com (8.8.5/8.8.5) with ESMTP id KAA10883 for ; Wed, 19 Mar 1997 10:20:41 -0500 (EST) Received: from celeste.switch.ch (localhost [127.0.0.1]) by celeste.switch.ch (8.8.5/8.8.5) with ESMTP id QAA16427; Wed, 19 Mar 1997 16:20:42 +0100 (MET) Date: Wed, 19 Mar 1997 16:20:41 +0100 (MET) Message-Id: <199703191520.QAA16427@celeste.switch.ch> From: Simon Leinen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: atommib@thumper.bellcore.com Subject: Access to actual shaping/policing parameters? The atmTrafficDescrParamTable can be used to specify traffic parameters for a VCL/VPL. Should there also be a way to access actual policing/shaping parameters at the endpoints of such links? -- Simon Leinen SWITCH   Received: from cnri by ietf.org id aa03637; 21 Mar 97 18:19 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa22871; 21 Mar 97 18:19 EST Received: from ihgw2.lucent.com (ihgw2.lucent.com [207.19.48.2]) by thumper.bellcore.com (8.8.5/8.8.5) with SMTP id RAA17168 for ; Fri, 21 Mar 1997 17:52:55 -0500 (EST) Received: from mtgbcs.mt.lucent.com by ihig2.firewall.lucent.com (SMI-8.6/EMS-L sol2) id QAA00994; Fri, 21 Mar 1997 16:46:42 -0600 From: dxie@mtgbcs.mt.lucent.com Received: from mtpcs52-102 by mtgbcs.mt.lucent.com (5.0/EMS-L sol2) id AA01708; Fri, 21 Mar 1997 17:53:54 -0500 Message-Id: <970321175744.ZM2887@mtpcs52-102> Date: Fri, 21 Mar 1997 17:57:42 -0400 In-Reply-To: Kaj Tesink "Re: SONET/SDH Suppl MIB" (Mar 18, 10:43am) References: <3.0.16.19970318104320.4a9fbb00@joker.bellcore.com> X-Mailer: Z-Mail 4.0 (4.0.0 Aug 21 1995) To: atommib@thumper.bellcore.com Subject: when the cross-connect's OperStatus is changed to down Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Atommibers: If an interface goes down (say receving some AIS signal), should the switch also change the OperStatus of the cross-connected PVCs that goes through that interfacem to down? Does the OperStatus of the cross-connected PVCs only indicate whether the "cross-connect" has been programmed into the hardware or also indicating that no good user cells are passing through the connection? Thanks. -- Dawn Xie   Received: from cnri by ietf.org id aa09616; 24 Mar 97 14:42 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa17197; 24 Mar 97 14:42 EST Received: from VNET.IBM.COM (vnet.ibm.com [199.171.26.4]) by thumper.bellcore.com (8.8.5/8.8.5) with SMTP id OAA11826 for ; Mon, 24 Mar 1997 14:09:58 -0500 (EST) Message-Id: <199703241909.OAA11826@thumper.bellcore.com> Received: from RALVM12 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 5253; Mon, 24 Mar 97 14:09:54 EST Date: Mon, 24 Mar 97 14:05:40 EST From: kennethw@vnet.ibm.com To: atommib@thumper.bellcore.com cc: ion@nexen.com Subject: Re: IpoaAtmAddr Alan Kullberg and I have been debating what the structure of a ATM Address should be in the IP over ATM MIB on the ion mailing list and I would like to have the advice of this mailing list. I am cross posting this so that any ion interested parties can follow the discussion. We had orginally imported AtmAddr from atm2tc. The problem with this is that it doesn't support structure 3 addresses and that the E.164 addresses are BCD encoded. Classic2 ATMARP uses native encoding for E.164 addresses as well as requiring support for structure 3 addresses. So currently I have defined a new textual convention as follows in the IPOA MIB: IpoaAtmAddr ::= TEXTUAL-CONVENTION DISPLAY-HINT "1x" STATUS current DESCRIPTION "The ATM address used by the network entity. The following address types can be inferred from the number of octets: Structure Octets Type - 0 no address 1 20 NSAP 2 8 E.164 encoded in BCD format 2 15 E.164 encoded in native format 3 28 BCD encode E.164 + NSAP sub-addr 3 35 native E.164 + NSAP sub-addr" An implementation may choose to represent a E.164 address in either native or BCD encoding." Could AtmAddr in atm2tc be changed to provide the support we need? Any thoughts on supporting native encodings for E.164 addresses? Thanks, Ken   Received: from cnri by ietf.org id aa19526; 24 Mar 97 20:04 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa23449; 24 Mar 97 20:04 EST Received: from one-o.com (canaan.one-o.com [206.151.128.11]) by thumper.bellcore.com (8.8.5/8.8.5) with SMTP id TAA21550 for ; Mon, 24 Mar 1997 19:43:48 -0500 (EST) Received: from jericho.one-o.com (jericho [206.151.128.12]) by one-o.com (SMI-8.6/SMI-SVR4-OOI951120) id QAA03372; Mon, 24 Mar 1997 16:43:46 -0800 Received: (from heard@localhost) by jericho.one-o.com (SMI-8.6/SMI-SVR4) id QAA06924; Mon, 24 Mar 1997 16:43:46 -0800 Date: Mon, 24 Mar 1997 16:43:46 -0800 Message-Id: <199703250043.QAA06924@jericho.one-o.com> To: atommib@thumper.bellcore.com Subject: T1.231-199x Letter Ballot Draft From: "C. M. Heard/VVNET, Inc." A new draft of T1.231-199x is available at the follwing URL: ftp://ftp.t1.org/pub/t1m1/7m130113.zip The contribution number is T1M1.3/97-011R3 and the file is a pkzip'ed Word for Windows document. Note: if you try to download the document and cannot find it at the above URL try ftp://ftp.t1.org/pub/t1m1/m1.3/7m130113.zip -- this is the usual place to find t1m1.3 documents, and it might move there. [ I will post my thoughts on what we should do for the sonet supplemental mib shortly; I still had some homework to do before this draft was posted, and now I have even more. ] Mike -- C. M. Heard VVNET, Inc. phone: +1 408 247 9376 4040 Moorpark Ave. Suite 206 fax: +1 408 244 3651 San Jose, CA 95117 USA e-mail: heard@vvnet.com   Received: from cnri by ietf.org id aa09581; 25 Mar 97 9:58 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa10678; 25 Mar 97 9:58 EST Received: from tbird.cc.bellcore.com (tbird.cc.bellcore.com [128.96.96.114]) by thumper.bellcore.com (8.8.5/8.8.5) with SMTP id JAA05573 for ; Tue, 25 Mar 1997 09:30:30 -0500 (EST) Received: from joker (joker.bellcore.com) by tbird.cc.bellcore.com with SMTP id AA05486 (5.67b/IDA-1.5 for ); Tue, 25 Mar 1997 09:30:14 -0500 Received: from nv-ktesink.cc.bellcore.com by joker (4.1/4.7) id AA17809; Tue, 25 Mar 97 09:32:17 EST Date: Tue, 25 Mar 97 09:32:17 EST X-Station-Sent-From: joker.bellcore.com Message-Id: <3.0.16.19970325093022.6a17e2b0@joker.bellcore.com> X-Sender: kaj@joker.bellcore.com X-Mailer: Windows Eudora Pro Version 3.0 (16) To: kennethw@vnet.ibm.com, atommib@thumper.bellcore.com From: Kaj Tesink Subject: Re: IpoaAtmAddr Cc: ion@nexen.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Hi Alan, The atm2tc has already been submitted to the NM-AD for processing as Draft. Of course there is still the official Last Call which may be utilized to make minor amendments. So if we would want to make this change I think the following conditions should be met: - the change must be a simple extension of the existing TC - the change must be based on consensus in both ion and atommib Kaj At 02:05 PM 3/24/97 EST, kennethw@vnet.ibm.com wrote: >Alan Kullberg and I have been debating what the structure of a >ATM Address should be in the IP over ATM MIB on the ion mailing >list and I would like to have the advice of this mailing list. >I am cross posting this so that any ion interested parties can >follow the discussion. > >We had orginally imported AtmAddr from atm2tc. The problem with this >is that it doesn't support structure 3 addresses and that the >E.164 addresses are BCD encoded. Classic2 ATMARP uses native encoding >for E.164 addresses as well as requiring support for structure 3 >addresses. So currently I have defined a new textual convention >as follows in the IPOA MIB: > > IpoaAtmAddr ::= TEXTUAL-CONVENTION > DISPLAY-HINT "1x" > STATUS current > DESCRIPTION > "The ATM address used by the network entity. > The following address types can be inferred > from the number of octets: > > Structure Octets Type > - 0 no address > 1 20 NSAP > 2 8 E.164 encoded in BCD format > 2 15 E.164 encoded in native format > 3 28 BCD encode E.164 + NSAP sub-addr > 3 35 native E.164 + NSAP sub-addr" > > An implementation may choose to represent a > E.164 address in either native or BCD encoding." > >Could AtmAddr in atm2tc be changed to provide the support we need? >Any thoughts on supporting native encodings for E.164 addresses? > >Thanks, Ken > > _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ _/ _/ _/ Kaj Tesink _/ _/ Bellcore _/ _/ - Emerging Networks vmail (908) 758-5254 _/ _/ 331 Newman Springs Rd. email kaj@cc.bellcore.com _/ _/ Red Bank, NJ 07701 faxmail (908) 758-4177 _/ _/ _/ _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/   Received: from cnri by ietf.org id aa18479; 25 Mar 97 11:03 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa12626; 25 Mar 97 11:03 EST Received: from bcarsde4.localhost (mailgate.nortel.ca [192.58.194.74]) by thumper.bellcore.com (8.8.5/8.8.5) with ESMTP id KAA08362 for ; Tue, 25 Mar 1997 10:44:19 -0500 (EST) Message-Id: <199703251544.KAA08362@thumper.bellcore.com> Received: from bcarsfba.ott.bnr.ca (actually bcarsfba.bnr.ca) by bcarsde4.localhost; Tue, 25 Mar 1997 10:33:09 -0500 Received: from bnr.ca by bcarsfba.bnr.ca id <14659-0@bcarsfba.bnr.ca>; Tue, 25 Mar 1997 10:35:29 -0500 Date: 25 Mar 1997 10:21 EST Sender: Chunhui Teng To: dxie@mtgbcs.mt.lucent.com Cc: Nalin Mistry , Robert Holt , Richard Vallee , Shedman Tam , atommib@thumper.bellcore.com From: Chunhui Teng Subject: re:when the cross-connect's OperStatus is changed to down I think the OperStatus should be down, according to draft-ietf-atommib-atm2TC-05.txt: AtmVorXOperStatus ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The value determines the operational status of a virtual link or cross-connect. The up and down states indicate that the traffic flow is enabled or disabled respectively on the virtual link or cross-connect. The unknown state indicates that the state of it cannot be determined. The state <---- will be down or unknown if the supporting ATM <---- interface(s) is down or unknown respectively." <---- SYNTAX INTEGER { up(1), down(2), unknown(3) } In message "when the cross-connect's OperStatus is changed to down", dxie@mtgbcs.mt.lucent.com writes: > Atommibers: > > If an interface goes down (say receving some AIS signal), should > the switch also change the OperStatus of the cross-connected > PVCs that goes through that interfacem to down? Does the > OperStatus of the cross-connected PVCs only indicate whether > the "cross-connect" has been programmed into the hardware or > also indicating that no good user cells are passing through the > connection? > > Thanks. > > -- Dawn Xie >   Received: from cnri by ietf.org id aa27433; 26 Mar 97 1:52 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa02976; 26 Mar 97 1:52 EST Received: from mx11.netvision.net.il (mx11.NetVision.net.il [194.90.1.52]) by thumper.bellcore.com (8.8.5/8.8.5) with ESMTP id BAA05657 for ; Wed, 26 Mar 1997 01:29:30 -0500 (EST) Received: from radmail.rad.co.il (radmail.rad.co.il [207.232.32.10]) by mx11.netvision.net.il (8.7.5/8.7.3) with ESMTP id JAA16080 for ; Wed, 26 Mar 1997 09:29:26 +0300 Received: from gate.radnet.co.il ([192.114.26.214]) by radmail.rad.co.il (post.office MTA v1.9.3 ID# 0-12126) with ESMTP id AAA15385 for ; Wed, 26 Mar 1997 08:32:31 +0200 Received: from orit (orit.radnet.co.il [192.115.241.53]) by gate.radnet.co.il (8.6.10/1.1) with SMTP id IAA24336 for ; Wed, 26 Mar 1997 08:28:51 +0200 Date: Wed, 26 Mar 1997 08:28:51 +0200 Message-Id: <1.5.4.16.19970326093221.4ce7ea2e@radnet1> X-Sender: orit@radnet1 X-Mailer: Windows Eudora Light Version 1.5.4 (16) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: atommib@thumper.bellcore.com From: orit Subject: Reuse of atmVp/VcCrossConnectIndex Hello, I have a question about the 'atmVpCrossConnectIndexNext' & 'atmVcCrossConnectIndexNext' variables from RFC 1695: Should there be any problem if I reuse index numbers of VP / VC cross connect entries after they are deleted (before I have used all (2^32-1) possible indexes)? Are there scenarios where the index of a cross connect must not be reused (maybe when gathering accounting data for billing purposes)? Thank you, Orit Levin Radnet Ltd., 24 Raul Wallenberg St., Tel-Aviv 69719, Israel Tel: +972-3-6455700 Direct Tel: +972-3-6455705 Fax: +972-3-6480582 E-Mail: orit@radnet.co.il   Received: from cnri by ietf.org id aa29260; 26 Mar 97 2:31 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa03587; 26 Mar 97 2:31 EST Received: from mx11.netvision.net.il (mx11.NetVision.net.il [194.90.1.52]) by thumper.bellcore.com (8.8.5/8.8.5) with ESMTP id CAA06277 for ; Wed, 26 Mar 1997 02:09:40 -0500 (EST) Received: from radmail.rad.co.il (radmail.rad.co.il [207.232.32.10]) by mx11.netvision.net.il (8.7.5/8.7.3) with ESMTP id KAA23509 for ; Wed, 26 Mar 1997 10:09:37 +0300 Received: from gate.radnet.co.il ([192.114.26.214]) by radmail.rad.co.il (post.office MTA v1.9.3 ID# 0-12126) with ESMTP id AAA16939 for ; Wed, 26 Mar 1997 09:12:43 +0200 Received: from orit (orit.radnet.co.il [192.115.241.53]) by gate.radnet.co.il (8.6.10/1.1) with SMTP id JAA26068 for ; Wed, 26 Mar 1997 09:09:02 +0200 Date: Wed, 26 Mar 1997 09:09:02 +0200 Message-Id: <1.5.4.16.19970326101232.0a4f0e2e@radnet1> X-Sender: orit@radnet1 X-Mailer: Windows Eudora Light Version 1.5.4 (16) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: atommib@thumper.bellcore.com From: orit Subject: Reuse of atmVp/VcCrossConnectIndex Hello, I have a question about the 'atmVpCrossConnectIndexNext' & 'atmVcCrossConnectIndexNext' variables from RFC 1695: Should there be any problem if I reuse index numbers of VP / VC cross connect entries after they are deleted (before I have used all (2^32-1) possible indexes)? Are there scenarios where the index of a cross connect must not be reused (maybe when gathering accounting data for billing purposes)? Thank you, Orit Levin Radnet Ltd., 24 Raul Wallenberg St., Tel-Aviv 69719, Israel Tel: +972-3-6455700 Direct Tel: +972-3-6455705 Fax: +972-3-6480582 E-Mail: orit@radnet.co.il   Received: from cnri by ietf.org id aa13147; 26 Mar 97 14:58 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa17858; 26 Mar 97 14:58 EST Received: from tbird.cc.bellcore.com (tbird.cc.bellcore.com [128.96.96.114]) by thumper.bellcore.com (8.8.5/8.8.5) with SMTP id OAA24723 for ; Wed, 26 Mar 1997 14:28:27 -0500 (EST) Received: from joker (joker.bellcore.com) by tbird.cc.bellcore.com with SMTP id AA16257 (5.67b/IDA-1.5 for ); Wed, 26 Mar 1997 14:27:59 -0500 Received: from nv-ktesink.cc.bellcore.com by joker (4.1/4.7) id AA25906; Wed, 26 Mar 97 14:30:02 EST Date: Wed, 26 Mar 97 14:30:02 EST X-Station-Sent-From: joker.bellcore.com Message-Id: <3.0.16.19970326142804.492f615a@joker.bellcore.com> X-Sender: kaj@joker.bellcore.com X-Mailer: Windows Eudora Pro Version 3.0 (16) To: Cynthia Clark From: Kaj Tesink Subject: Posting Cc: atommib@thumper.bellcore.com, if-mib@vndad.tek.com, kaj@joker.bellcore.com Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_859415307==_" --=====================_859415307==_ Content-Type: text/plain; charset="us-ascii" Hi Cynthia, Please post as . Thanks again, Kaj --=====================_859415307==_ Content-Type: text/plain; charset="us-ascii" Content-Disposition: attachment; filename="TEST.RFC" INTERNET-DRAFT System/Interface Test MIB March 1997 Definitions of Managed Objects for System and Interface Testing March, 1997 Maria Greene Ascom Nexion greene@nexen.com Keith McCloghrie Cisco Systems kzm@cisco.com Kaj Tesink Bell Communications Research kaj@cc.bellcore.com Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as a "work in progress". To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Expires September 1997 [Page 1] INTERNET-DRAFT System/Interface Test MIB March 1997 Abstract This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for testing systems and interfaces. This memo replaces the objects originally defined in the ifTestGroup of RFC1573, the IF-MIB [6], which have been deprecated. This memo specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions. This memo does not specify a standard for the Internet community. 1. The SNMP Network Management Framework The SNMP Network Management Framework presently consists of three major components. They are: o the SMI, described in RFC 1902 [1] - the mechanisms used for describing and naming objects for the purpose of management. o the MIB-II, STD 17, RFC 1213 [2] - the core set of managed objects for the Internet suite of protocols. o the protocol, RFC 1157 [3] and/or RFC 1905 [4], - the protocol for accessing managed objects. The Framework permits new objects to be defined for the purpose of experimentation and evaluation. 1.1. Object Definitions Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the subset of Abstract Syntax Notation One (ASN.1) defined in the SMI. In particular, each object type is named by an OBJECT IDENTIFIER, an administratively assigned name. The object type together with an object instance serves to uniquely identify a specific instantiation of the object. For human convenience, we often use a textual string, termed the descriptor, to also refer to the object type. Expires September 1997 [Page 2] INTERNET-DRAFT System/Interface Test MIB March 1997 2. Experience with the Interfaces Test Group The ifTestGroup of objects defined in RFC1573 has not been used widely. Some cited problems were: o Few standard tests had been defined to date. o Some well known tests had already been written on a media- specific basis, e.g., DS1 loopback. o The ifTestGroup allowed for interface testing only. o A logging capability was missing. As a result, the ifTestGroup and associated ifTestTable have been deprecated. However, since renewed interest was expressed in a generic testing capability, specifically in the development of MIBs for managing Asynchronous Transfer Mode interfaces, a set of requirements have been defined that form the basis for the design of the generic Test MIB defined in this memo. 3. Requirements for a Generic Test MIB This section describes the requirements that have been identified for a generic test MIB. 3.1. Test Identification The system defined in RFC1573 to identify tests relies on OBJECT IDENTIFIERs. This system is flexible in that it allows additional tests to be defined over time and autonomously by vendors, removing the need to register test types in a single place. This mechanism for test identification has been retained. Expires September 1997 [Page 3] INTERNET-DRAFT System/Interface Test MIB March 1997 3.2. Test Targets With the advent of an increasing number of non-interface related MIB modules it is desirable to define a test capability that allows testing of interfaces and non-interface physical entities. The following possibilities were considered: a) Separate test capabilities for interface tests and other tests. b) The use of a single test capability where the test target would be defined within the test table. This memo uses the latter approach and uses an object with the syntax RowPointer to identify test targets. (Initially, the use of the Entity MIB was considered for identification of test targets, but this was abandoned because this would require support of the Entity MIB for testing purposes.) Tests are listed in the testTable. The entries in the testTable are distinguished through the value of a simple integer called testIndex. Expires September 1997 [Page 4] INTERNET-DRAFT System/Interface Test MIB March 1997 3.3. Logging Results A logging capability of test results serves to store the test results for some period of time. Two mechanisms were considered: 1) Separate the test capability and the log. 2) Combine the test capability and the log in a single table. Note that searching criteria on the log relate to this choice as well. The log length is necessarily limited. The following choices were considered: 1) Age the entries. 2) Limit by the number of entries. 3) A system that allows either 1) or 2). This MIB module chooses a system where the test and logging capability have been combined in a single table (testTable). The log length is limited by a read-write object (testTableMaxSize). This MIB module also defines a notification, testComplete, which contains the same information as the log entry. Therefore, an agent with limited resources can limit the maximum size of the log to a very few number of entries and rely on a management application to receive and log the testComplete notifications. 3.4. Log Searching Efficient searching in a log is a key to its effectiveness. The following possibilities were considered: a) Sort on age of the entries. b) Sort on test type. c) Sort on combinations of the above. Expires September 1997 [Page 5] INTERNET-DRAFT System/Interface Test MIB March 1997 This MIB module chooses for the index testIndex, which is an integer identifier for an invocation of a test. To obtain a new testIndex a manager retrieves the value of testIndexNext. Each time this object is read the next lower available value is provided. This addresses the requests that are expected to be most common: o What is the result of test (testIndex)? o What are the results of the last n tests? Since the testIndex has been defined as decreasing, this approach will order log entries by time, newest to oldest. The possibility of testId wrapping is minimized by having it restart at its maximum value and when the agent restarts. When a manager is interested in a specific test, a specific get-request may be issued. When a manager is interested in the latest n tests for the system, getnext/bulk starting from (testIndex) provides the approximate answer. 3.5. Determining Agent Test Capabilities A testCapabilitiesTable has been defined to list the tests that can be performed through this agent. Expires September 1997 [Page 6] INTERNET-DRAFT System/Interface Test MIB March 1997 4. Definitions TEST-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Unsigned32, experimental, NOTIFICATION-TYPE, mib-2 FROM SNMPv2-SMI AutonomousType, RowPointer, TimeStamp, RowStatus FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF OwnerString FROM IF-MIB ; testMIB MODULE-IDENTITY LAST-UPDATED "9703111200Z" ORGANIZATION "IETF IFMIB Working Group" CONTACT-INFO "Keith McCloghrie Postal: Cisco Systems 170 West Tasman Drive San Jose, CA 95134 US Tel: +1 408 526 5260 E-mail: kzm@cisco.com Kaj Tesink Postal: Bell Communications Research 331 Newman Springs Road Red Bank, NJ 07701 US Tel: +1 908 758 5254 E-mail: kaj@cc.bellcore.com Maria Greene Postal: Ascom Nexion 289 Great Road Acton, MA 01720 US Tel: +1 508 266 4570 E-mail: greene@nexen.com" DESCRIPTION "This MIB module provides a generic test capability." -- ******** NOTE TO THE RFC EDITOR ************** Expires September 1997 [Page 7] INTERNET-DRAFT System/Interface Test MIB March 1997 -- In case this module is put on the standards track -- replace the following: -- "::= {experimental XX}" with -- "::= { mib-2 YY }" ::= { experimental XX } testMIBObjects OBJECT IDENTIFIER ::= { testMIB 1 } testIndexNext OBJECT-TYPE SYNTAX INTEGER (0..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains an appropriate value to be used for testIndex when creating entries in the testTable. The value 0 indicates that no unassigned entries are available. To obtain the testIndex value for a new entry, the manager issues a management protocol retrieval operation to obtain the current value of this object. After each retrieval, the agent should modify the value to the next lower unassigned index. If the agent is restarted this object shall be set to its highest value." ::= { testMIBObjects 1 } -- The Test Table testTable OBJECT-TYPE SYNTAX SEQUENCE OF TestEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table is used to initiate tests. An entry in this table corresponds to an instance of a test. A test is invoked by creating a row with the appropriate test attributes and using testRowStatus to start a test. After invoking a test, the object testResult can be read to determine the outcome. If an agent can not perform the test, testResult is set accordingly. The testCode can be used to provide further test-specific or entity- specific (or even enterprise-specific) information Expires September 1997 [Page 8] INTERNET-DRAFT System/Interface Test MIB March 1997 concerning the outcome of the test. Only one test can be in progress on each entity at any one time. If one test is in progress when another test is invoked, the second test is rejected. Some agents may reject a test when a prior test is active on another entity. Before starting a test, a manager-station must first obtain 'ownership' of the entry in the testTable for the entity to be tested. This is accomplished by retrieving the value of testIndexNext. This value entitles the manager to create a row in the testTable with the value of testIndex being equal to the retrieved value of testIndexNext. Once ownership is obtained, the test parameters can be setup, and then the test is initiated by activating the row through testRowStatus. The agent sets the value of testResult to 'inProgress'. On completion of the test, the agent sets testResult and testCode in accordance with the test results and sets the testCompletionTime. If testRowStatus is not set to active within an abnormally long period of time after ownership is obtained, the agent should time-out the manager, and reset the value of the testRowStatus object back to 'destroy'. It is suggested that this time-out period be 5 minutes. In general, a management station must not retransmit a request to invoke a test for which it does not receive a response; instead, it properly inspects an agent's MIB to determine if the invocation was successful. Only if the invocation was unsuccessful, is the invocation request retransmitted. Some tests may require the entity to be taken off- line in order to execute them, or may even require the agent to reboot after completion of the test. In these circumstances, communication with the management station invoking the test may be lost until after completion of the test. An agent is not required to support such tests. However, if such tests are supported, then the agent should make every effort to transmit a response to the request which invoked the test prior to losing communication. When the agent is restored to normal service, the results of the test are properly made Expires September 1997 [Page 9] INTERNET-DRAFT System/Interface Test MIB March 1997 available in the appropriate objects. Note that this requires that the testIndex value assigned to an entity must be unchanged even if the test causes a reboot. An agent must reject any test for which it cannot, perhaps due to resource constraints, make available at least the minimum amount of information after that test completes." ::= { testMIBObjects 2 } testEntry OBJECT-TYPE SYNTAX TestEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry containing objects for invoking a test." INDEX { testIndex } ::= { testTable 1 } TestEntry ::= SEQUENCE { testIndex Unsigned32, testTarget RowPointer, testType AutonomousType, testCompletionTime TimeStamp, testResult INTEGER, testCode OBJECT IDENTIFIER, testOwner OwnerString, testRowStatus RowStatus } testIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The index of this table." ::= { testEntry 1 } testTarget OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-create STATUS current DESCRIPTION "The target of the test. An example of a test target is an instance of an interface, identified by the OID 'ifIndex.17'." DEFVAL { { 0 0 } } Expires September 1997 [Page 10] INTERNET-DRAFT System/Interface Test MIB March 1997 ::= { testEntry 2 } testType OBJECT-TYPE SYNTAX AutonomousType MAX-ACCESS read-create STATUS current DESCRIPTION "The identifier that specifies the test. OBJECT IDENTIFIER values assigned to tests are defined elsewhere, in association with specific types of entity. However, this document assigns a value for a full- duplex loopback test, and defines the special meanings of the subject identifier: noTest OBJECT IDENTIFIER ::= { 0 0 } When the value noTest is written to this object, no action is taken. " DEFVAL { { 0 0 } } ::= { testEntry 3 } testCompletionTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when the test completed." ::= { testEntry 4 } testResult OBJECT-TYPE SYNTAX INTEGER { none(1), -- no test yet requested success(2), inProgress(3), notSupported(4), unAbleToRun(5), -- due to state of system aborted(6), failed(7) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the result of the most recently requested test, or the value 'none(1)' if no test has been started yet." DEFVAL { none } Expires September 1997 [Page 11] INTERNET-DRAFT System/Interface Test MIB March 1997 ::= { testEntry 5 } testCode OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains a code which contains more specific information on the test result, for example an error-code after a failed test or a result value such as round trip time for a 'ping' test. Error codes and other values this object may take are specific to the type of entity and/or test. The value may have the semantics of AutonomousType, InstancePointer, RowPointer or VariablePointer textual conventions as defined in RFC 1903. The identifier: testCodeNone OBJECT IDENTIFIER ::= { 0 0 } is defined for use if no additional result code is available." DEFVAL { { 0 0 } } ::= { testEntry 6 } testOwner OBJECT-TYPE SYNTAX OwnerString MAX-ACCESS read-create STATUS current DESCRIPTION "The manager which currently has the 'ownership' required to invoke a test on this entity." ::= { testEntry 7 } testRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of the test: - When the manager activates the row the test is started. - When the test is completed the row will remain active or may be destroyed by the manager. - Details of ongoing or just completed tests are reported in testResult and testCode. - A manager may abort ongoing tests or remove completed test information by setting the row status to destroy." Expires September 1997 [Page 12] INTERNET-DRAFT System/Interface Test MIB March 1997 DEFVAL { active } ::= { testEntry 8 } -- Table size testTableMaxSize OBJECT-TYPE SYNTAX Unsigned32 (10..4294967295) MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum number entries in the testTable. When the table reaches this size the oldest entries will be discarded when new entries are added. The table is flushed when the agent is reset." ::= { testMIBObjects 3 } -- Test Capabilities Table testCapabilitiesTable OBJECT-TYPE SYNTAX SEQUENCE OF TestCapabilitiesEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains the test that this entity is able to invoke." ::= { testMIBObjects 4 } testCapabilitiesEntry OBJECT-TYPE SYNTAX TestCapabilitiesEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry in this table represents a test." INDEX { testCapabilitiesIndex } ::= { testCapabilitiesTable 1 } TestCapabilitiesEntry ::= SEQUENCE { testCapabilitiesIndex Unsigned32, testCapabilitiesType AutonomousType } testCapabilitiesIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible Expires September 1997 [Page 13] INTERNET-DRAFT System/Interface Test MIB March 1997 STATUS current DESCRIPTION "An integer index that uniquely identifies the entry." ::= { testCapabilitiesEntry 1 } testCapabilitiesType OBJECT-TYPE SYNTAX AutonomousType MAX-ACCESS read-only STATUS current DESCRIPTION "The type of test that can be invoked." ::= { testCapabilitiesEntry 2 } -- Notifications testMIBNotifications OBJECT IDENTIFIER ::= { testMIB 0 } testComplete NOTIFICATION-TYPE OBJECTS { testIndex, testTarget, testType, testResult, testCode, testOwner } STATUS current DESCRIPTION "A testComplete trap signifies that a test has completed for a particular entity. If the testCode has the semantics of a VariablePointer, the variable it points at will also be included in the objects list." ::= { testMIBNotifications 1 } -- Conformance Information testMIBConformance OBJECT IDENTIFIER ::= { testMIB 3 } testMIBGroups OBJECT IDENTIFIER ::= { testMIBConformance 1 } testMIBCompliances OBJECT IDENTIFIER ::= { testMIBConformance 2 } Expires September 1997 [Page 14] INTERNET-DRAFT System/Interface Test MIB March 1997 -- Compliance Statements testMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP agents which support generic testing capabilities." MODULE -- this module MANDATORY-GROUPS { testMIBGroup, testNotificationGroup } OBJECT testMaxSize MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { testMIBCompliances 1 } -- Units of Conformance testMIBGroup OBJECT-GROUP OBJECTS { testIndexNext, testTarget, testType, testCompletionTime, testResult, testCode, testOwner, testRowStatus, testTableMaxSize, testCapabilitiesType } STATUS current DESCRIPTION "A collection of objects providing a generic test capability." ::= { testMIBGroups 1 } testNotificationGroup NOTIFICATION-GROUP NOTIFICATIONS { testComplete } STATUS current DESCRIPTION Expires September 1997 [Page 15] INTERNET-DRAFT System/Interface Test MIB March 1997 "The notifications used to indicate test completion." ::= { testMIBGroups 2 } END 5. Acknowledgments This document is a product of the IETF's Interfaces MIB Working Group. The original ifTestTable was the work of Keith McCloghrie (Cisco) and Frank Kastenholz (FTP Software) and has been used in this further evolution. The authors would like to acknowledge the following individuals for their input on requirements: James Watt (Newbridge) Dave Fowler (Newbridge) Steven Buchko (Newbridge) Milt Rosslinsky (ACC) Dawn Xie (Lucent) Chris Martin (Netedge) Expires September 1997 [Page 16] INTERNET-DRAFT System/Interface Test MIB March 1997 6. References [1] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC1902, SNMP Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [2] McCloghrie, K., and M. Rose, Editors, "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", STD 17, RFC 1213, Hughes LAN Systems, Performance Systems International, March 1991. [3] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", RFC 1157, SNMP Research, Performance Systems International, Performance Systems International, MIT Laboratory for Computer Science, May 1990. [4] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC1905, SNMP Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [5] McCloghrie, K., and A. Bierman, Editors, "Entity MIB", RFC2037, Cisco Systems, January 1996. [6] Kastenholz, F., "Definitions of Managed Objects for the Ethernet- like Interface Types using SMIv2", RFC1650, FTP Software, Inc, August 1994. [6] McCloghrie, K., Kastenholz, F., "Evolution of the Interfaces Group of MIB-II", RFC1573, (should be updated to new IF-MIB RFC#) Cisco Systems, Inc., FTP Software, January 1994. [7] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Textual Conventions for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC1903, SNMP Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. Expires September 1997 [Page 17] INTERNET-DRAFT System/Interface Test MIB March 1997 7. Security Considerations Security issues are not discussed in this memo. 8. Authors' Addresses Maria Greene Ascom Nexion 289 Great Road Acton, MA 01720-4739 Phone: (508) 266-4570 EMail: greene@nexen.com Keith McCloghrie Cisco Systems 170 West Tasman Drive San Jose, CA 95134 Phone: (408) 526-5260 E-mail: kzm@cisco.com Kaj Tesink Bell Communications Research Room 1A-427 331 Newman Springs Road P.O. Box 7020 Red Bank, NJ 07701-7020 Phone: (908) 758-5254 EMail: kaj@cc.bellcore.com Expires September 1997 [Page 18] INTERNET-DRAFT System/Interface Test MIB March 1997 Table of Contents 1 The SNMP Network Management Framework ........................ 2 1.1 Object Definitions ......................................... 2 2 Experience with the Interfaces Test Group .................... 3 3 Requirements for a Generic Test MIB .......................... 3 3.1 Test Identification ........................................ 3 3.2 Test Targets ............................................... 4 3.3 Logging Results ............................................ 5 3.4 Log Searching .............................................. 5 3.5 Determining Agent Test Capabilities ........................ 6 4 Definitions .................................................. 7 5 Acknowledgments .............................................. 16 6 References ................................................... 17 7 Security Considerations ...................................... 18 8 Authors' Addresses ........................................... 18 Expires September 1997 [Page 19] --=====================_859415307==_--   Received: from cnri by ietf.org id aa17999; 26 Mar 97 16:09 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa19782; 26 Mar 97 16:09 EST Received: from tbird.cc.bellcore.com (tbird.cc.bellcore.com [128.96.96.114]) by thumper.bellcore.com (8.8.5/8.8.5) with SMTP id PAA27222 for ; Wed, 26 Mar 1997 15:40:00 -0500 (EST) Received: from joker (joker.bellcore.com) by tbird.cc.bellcore.com with SMTP id AA21432 (5.67b/IDA-1.5 for ); Wed, 26 Mar 1997 15:39:44 -0500 Received: from nv-ktesink.cc.bellcore.com by joker (4.1/4.7) id AA26327; Wed, 26 Mar 97 15:41:46 EST Date: Wed, 26 Mar 97 15:41:46 EST X-Station-Sent-From: joker.bellcore.com Message-Id: <3.0.16.19970326154008.492f057a@joker.bellcore.com> X-Sender: kaj@joker.bellcore.com X-Mailer: Windows Eudora Pro Version 3.0 (16) To: Cynthia Clark From: Kaj Tesink Subject: Posting Cc: atommib@thumper.bellcore.com, kaj@joker.bellcore.com Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_859419611==_" --=====================_859419611==_ Content-Type: text/plain; charset="us-ascii" Hi Cynthia, Please post as . Thanks, Kaj --=====================_859419611==_ Content-Type: text/plain; charset="us-ascii" Content-Disposition: attachment; filename="ATMTEST.RFC" Definitions of Tests for ATM Management March 1997 Michael Noto (editor) Network Equipment Technologies mike_noto@net.com Kaj Tesink (editor) Bell Communications Research kaj@cc.bellcore.com 1. Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as a "work in progress". To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). draft ATM Test Objects March 1997 2. Introduction This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for managing ATM-based interfaces, devices, networks and services in addition to those defined in the ATM MIB [1], to provide additional support for the management of ATM Loopback Tests. 3. The SNMPv2 Network Management Framework The SNMPv2 Network Management Framework consists of four major components. They are: 0 RFC 1902 [2] which defines the SMI, the mechanisms used for describing and naming objects for the purpose of management. 0 STD 17, RFC 1213 [3] defines MIB-II, the core set of managed objects for the Internet suite of protocols. 0 RFC 1157 [4] and RFC 1905 [5] which define two versions of the protocol used for network access to managed objects. The Framework permits new objects to be defined for the purpose of experimentation and evaluation. Expires September 1997 [Page 2] draft ATM Test Objects March 1997 4. Object Definitions Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the subset of Abstract Syntax Notation One (ASN.1) defined in the SMI. In particular, each object type is named by an OBJECT IDENTIFIER, an administratively assigned name. The object type together with an object instance serves to uniquely identify a specific instantiation of the object. For human convenience, we often use a textual string, termed the descriptor, to also refer to the object type. 5. Overview The purpose of this memo is to provide additional capabilities, not found in the ATM MIB [1], which are needed to manage ATM interfaces. This memo addresses ATM Testing Support. 5.1. Background In addition to the MIB module defined in this memo, other MIB modules are necessary to manage ATM interfaces, links and cross-connects. Examples include MIB II for general system [3] and interface management [6], the DS3 or SONET MIBs for management of SONET and DS3 physical interfaces, and, as appropriate, MIB modules for applications that make use of ATM, such as SMDS and LAN Emulation. These MIB modules are outside the scope of this specification. This MIB module also requires the use of the ATM MIB module defined in [1]. This memo proposes extensions to the ATM MIB in order to support ATM Loopback Tests. An ATM Loopback Test provides the ability to send out a loopback OAM (Operations and Maintenance) cell to verify the exisitence of connectivity for a particular connection. The current specification of this supplemental ATM MIB is based on SNMPv2 SMI. Expires September 1997 [Page 3] draft ATM Test Objects March 1997 5.2. Important Definitions The following terms are defined here and used throughout this MIB: - Virtual Path Link (VPL) - Virtual Path Connection (VPC) - Virtual Path Segment (VP Segment) - Virtual Channel Link (VCL) - Virtual Channel Connection (VCC) - Virtual Channel Segment (VC Segment). _____ _______ _______ _______ _____ | |____| |____| |____| |____| | |Host1| |SwitchA| |SwitchB| |SwitchC| |Host2| | |____| |____| |____| |____| | |_____| |_______| |_______| |_______| |_____| |<----->| Virtual |<----->| Virtual Path Link Path Link |<------------Virtual Path Connection---------->| (between Host1 and Host2) |<--------------->| Virtual Path Segment (between SwitchA and SwitchC) Figure 1: Examples of Virtual Path Links, Virtual Path Connection, and Virtual Path Segment Expires September 1997 [Page 4] draft ATM Test Objects March 1997 _____ _______ _______ _______ _____ | |____| |____| |____| |____| | |Host1|----|SwitchA|----|SwitchB|----|SwitchC|----|Host2| | |____| |____| |____| |____| | |_____| |_______| |_______| |_______| |_____| |<----->| Virtual |<----->| Virtual Channel Link Channel Link |<----------Virtual Channel Connection--------->| (between Host1 and Host2) |<--------------->| Virtual Channel Segment (between SwitchA and SwitchC) Figure 2: Examples of Virtual Channel Links, Virtual Channel Connection, and Virtual Channel Segment 5.3. Supported Functions The managed ATM objects are arranged into the following groups: I. ATM Testing Support: (1) ATM Loopback Testing Group (2) ATM End-Point Group. 5.3.1. ATM Testing Support 5.3.1.1. ATM Loopback Testing Group The loopback test provides the ability to send out a loopback OAM cell to verify the existence of connectivity for a particular connection. Loopback tests can be performed on either an entire connection (i.e., an end-to-end test), a segment of the connection (i.e., a segment test), a portion of a segment (i.e., a loopback location identifier test), or the network portion of a connection (i.e., a service internal test). Expires September 1997 [Page 5] draft ATM Test Objects March 1997 The loopback test makes use of the Test Table defined in [10]. For a given interface, a loopback test can be invoked by obtaining ownership of a test and then by setting the value of 'testType' equal to one of the ATM Loopback Test Types defined in Section (8). See procedures in [10] for using the Test Table. After invoking a loopback test, the object 'testResult' can be read to determine the outcome of the loopback test (e.g., success(2) if the loopback cell made it back to the originator of the test or failed(7) if the loopback cell did not make it back). This group contains the following types of loopback tests: - End-to-end Loopback Test - Segment Loopback Test - Loopback Test Using Loopback Location Identifier - Network Loopback Test. 1) End-to-end Loopback Test The end-to-end loopback (LB) is self-explanatory. For a VP test, the cell is sent on the given VP, via VCI=4 specified in [8]. For a VC test, the LB cell is sent on the VC under test, with the PTI (Payload Type Indicator) set to 5 as specified in [8]. Figure 3 illustrates the end-to-end loopback test. ____ _______ _______ _______ ____ |Host| | | | | | | |Host| |____|----|SwitchA|----|SwitchB|----|SwitchC|----|____| |_______| |_______| |_______| |<--------------------------------------------->| Test Path Figure 3: End-to-end Loopback Test See Section (8) for more details on how to use the End-to-end Loopback Test. 2) Segment Loopback Test Expires September 1997 [Page 6] draft ATM Test Objects March 1997 The segment LB test is explained in ITU-T I.610[9]. For a VP segment test, the LB cell is sent on the VP under test via VCI=3 as specified in [8], and the Loopback Location ID field is set to all 1's. For a VC segment test, the LB cell is sent on the VC under test, with the PTI set to 4 as specified in [8], and the Loopback Location ID field is set to all 1's. This test involves a LB cell being inserted at a pre-defined segment end-point, and looped back at the corresponding segment end-point encountered. The pair of segment end-points define a segment (which is used for the segment loopback test). A VP/VC connection can have multiple segments, but multiple segments cannot overlap. A UNI interface is by definition defined as a segment end- point (hence a UNI would be considered a segment). A segment can also define: - a B-ICI - a public carrier's 'piece' of the connection - a private network's 'piece' of the connection. In order to support this functionality, the VP/VC link termination needs to be able to be defined as a segment. This can be done using either the atmVplSegmentEndPoint or atmVclSegmentEndPoint object depending on whether it is for a VPC or VCC. A segment loopback test is illustrated in Figure 4. ____ _______ _______ _______ ____ |Host| | | | | | | |Host| |____|----|SwitchA|----|SwitchB|----|SwitchC|----|____| |_______| |_______| |_______| |<----------------------->| Segment Figure 4: Segment Loopback Test Section (8) describes the use of the ATM Segment Loopback Tests. 3) Loopback Test Using Loopback Location Identifier Expires September 1997 [Page 7] draft ATM Test Objects March 1997 This loopback test is a special type of 2) where the Loopback Location ID field is set to a value that corresponds to a specific node in a given network (Note that the format of this field is not standardized, that is, the value is significant only within an administrative domain). In this case, the device initiating the LB test inserts the appropriate Loop Back Location ID. When the LB cell reaches the corresponding device, that device recognizes the Loopback Location ID as its own, and loops it back. This test is useful for performing fault sectionalization without having to provision segment end-points. An additional object, the atmLoopbackID, is defined to determine the loopback point. Figure 5 shows a loopback test using a location identifier. Note that the loopback test using location identifier can be used to perform a loopback test over a portion of a defined segment. See Figure 5. ____ _______ _______ _______ ____ |Host| | | | | | | |Host| |____|----|SwitchA|----|SwitchB|----|SwitchC|----|____| |_______| |_______| |_______| |<---------->| Portion of Segment that Loopback test is performed on |<----------------------->| Segment Figure 5: Loopback Test Using Location Identifier See Section (8) for more details. 4) Network Loopback Test This is a loopback test that the manager requests an agent in a network to perform over the internal portion of a designated connection. The Network then initiates the internal network loopback test by inserting an OAM loopback cell at one of the end-points of the internal network portion of the connection. When the loopback cell reaches the other end-point of the internal Network , the cell is looped back. This test is useful for verifying connectivity through a particular network. Figure 6 illustrates the Network loopback test. Expires September 1997 [Page 8] draft ATM Test Objects March 1997 ____ _______ _______ _______ ____ |Host| |Netwk 1| |Netwk 1| |Netwk 1| |Host| |____|----|SwitchA|----|SwitchB|----|SwitchC|----|____| |_______| |_______| |_______| |<----------------------->| LB Test Path thru Network 1 Figure 6: Network Loopback Test See Section (8) for more details. 5.3.1.2. ATM End-Point Group The ATM End-Point Group contains two tables: the ATM VP End- point Table and the ATM VC End-point Table. The ATM VP End- point Table augments the atmVplTable and provides the atmVplEndptSegmentEndPoint object to represent whether or not a specified VPL is a segment end-point. Similarly for Virtual Channels, the ATM VC End-point Table and the atmVclEndptSegmentEndPoint object are used to represent whether or not a specified VCL is a segment end-point. Expires September 1997 [Page 9] draft ATM Test Objects March 1997 6. Definitions ATMTEST-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-IDENTITY, OBJECT-TYPE, experimental FROM SNMPv2-SMI MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF mib-2 FROM RFC1213-MIB atmVplEntry, atmVclEntry FROM ATM-MIB; atmTESTMIB MODULE-IDENTITY LAST-UPDATED "9703251200Z" ORGANIZATION "IETF AToMMIB Working Group" CONTACT-INFO " Michael Noto Postal: Network Equipment Technologies 800 Saginaw Drive RM 21.1.111 Redwood City, CA 94063 Tel: +1 415 569-7134 E-mail: noto@net.com Kaj Tesink Postal: Bell Communications Research 331 Newman Springs Road Red Bank, NJ 07701 US Tel: +1 908 758 5254 Fax: +1 908 758 4177 E-mail: kaj@cc.bellcore.com" DESCRIPTION "This MIB Module provides ATM Loopback Tests and supporting objects that must be supported by ATM devices providing ATM Loopback Tests." ::= { experimental XX } atmTESTMIBObjects OBJECT IDENTIFIER ::= {atmTESTMIB 1} -- ******** NOTE TO THE RFC EDITOR ************** Expires September 1997 [Page 10] draft ATM Test Objects March 1997 -- In case this module is put on the standards track -- replace the following: -- "atmTESTMIB MODULE-IDENTITY ::= {experimental XX}" with -- "atmTESTMIB MODULE-IDENTITY ::= {mib-2 YY}" -- and assign YY by IANA. -- This ATMTEST-MIB Module consists of the following groups: -- ATM Testing Support: -- (1) ATM Loopback Testing Group -- (2) ATM End-Point Group Expires September 1997 [Page 11] draft ATM Test Objects March 1997 -- ************************************************ -- (1) ATM Loopback Testing Group -- This group contains information for interfaces -- supporting ATM Loopback Tests -- This group includes the following: -- 1. ATM Loopback Objects -- 2. List of ATM Loopback Test Types atmLoopbackTestGroup OBJECT IDENTIFIER::= { atmTESTMIBObjects 1} -- 1. ATM Loopback Objects -- The following objects are defined for use in -- performing ATM Loopback Tests. atmLoopbackID OBJECT-TYPE SYNTAX OCTET STRING(SIZE(16)) MAX-ACCESS read-write STATUS current DESCRIPTION "This identifier is used to identify this local ATM device. The value of this object can be used by other ATM devices to identify this local ATM device as the device that is being requested to loopback the OAM Loopback cell. The default for this field is all 1's, which would indicate a segment OAM Loopback Test. Location Identifiers of less than 16 octets are left justified, and padded with all '0's." DEFVAL { 'ffffffffffffffffffffffffffffffff'H } ::= { atmLoopbackTestGroup 1 } -- 2. List of ATM Loopback Test Types -- The following loopback test types are defined: -- atmLoopbackVpE2e -- atmLoopbackVcE2e -- atmLoopbackVpSegment -- atmLoopbackVcSegment -- atmLoopbackVpLocationID -- atmLoopbackVcLocationID -- atmLoopbackVpServcInternal -- atmLoopbackVcServcInternal Expires September 1997 [Page 12] draft ATM Test Objects March 1997 atmLoopbackTestTypes OBJECT IDENTIFIER ::= { atmLoopbackTestGroup 4 } atmLoopbackVpE2e OBJECT-IDENTITY STATUS current DESCRIPTION "This is an end-to-end loopback test performed on a designated VP (Virtual Path). To perform this test an end-to-end loopback OAM cell is inserted at one of the end-points of the designated VP connection (e.g., at a host) via VCI=4 (the VCI value for VP OAM end-to-end cells), travels to the other end- point of the VP connection, and then loops back to the originating end-point on the designated VP. Success is achieved if the loopback OAM cell returns to the originating end-point within 5 seconds, otherwise, the test fails. The manager-station performs a loopback test by making use of the testTable) defined in [10]. In order to run this test the object 'testType' in the testTable shall be set to atmLoopbackVpE2e, and the object testTarget points to the row in the atmVplTable in [1] corresponding to the VP designated for the test. Before starting a test, a manager-station must first obtain 'ownership' of the entry in the testTable for the interface to be tested (follow procedure defined in [10]). Once the manager- station obtains ownership, a loopback test for a given interface can be invoked by first setting up parameters necessary for the loopback test (e.g., set the testTarget), and then setting the value of 'testType' in the testTable equal to 'atmLoopbackVpE2e'. This will cause the atmLoopbackVpE2e test to be invoked on the VP with the VPI corresponding to the testTarget. After invoking a loopback test, wait for the test completion by polling for the object 'testResult'. A value of 'inProgress(3)' will result if the test is still in progress. Once the test is completed, the object 'testResult' will have a value of Expires September 1997 [Page 13] draft ATM Test Objects March 1997 'success(2)' if the loopback OAM cell returned to the originator of the test within 5 seconds, if not, a value of 'failed(7)' will result. If the ATM system does not support this type of loopback test, then a value of 'notSupported(4)' will be provided. Other possible values for the 'testResult' object are 'unAbleToRun(5)' and 'aborted(6)'." ::= { atmLoopbackTestTypes 1 } atmLoopbackVcE2e OBJECT-IDENTITY STATUS current DESCRIPTION "This is an end-to-end loopback test performed on a designated VC (Virtual Channel). To perform this test an end-to-end loopback OAM cell is inserted at one of the end-points of the designated VC connection (e.g., at a host) via PTI=5 (the PTI value used for VC OAM end-to-end cells), travels to the other end-point of the VC connection, and then loops back to the originating end-point on the designated VC. Success is achieved if the loopback OAM cell returns to the originating end-point within 5 seconds, otherwise, the test fails. The manager-station performs a loopback test by making use of the testTable) defined in [10]. In order to run this test the object 'testType' in the testTable shall be set to atmLoopbackVcE2e, and the object testTarget points to the row in the atmVclTable in [1] corresponding to the VC designated for the test. Before starting a test, a manager-station must first obtain 'ownership' of the entry in the testTable for the interface to be tested (follow procedure defined in [10]). Once the manager-station obtains ownership, a loopback test for a given interface can be invoked by first setting up parameters necessary for the loopback test (e.g., set the testTarget), and then setting the value of 'testType' in the testTable equal to 'atmLoopbackVcE2e'. This will cause the atmLoopbackVcE2e test to be invoked on the VC with the VPI/VCI corresponding to the testTarget. Expires September 1997 [Page 14] draft ATM Test Objects March 1997 After invoking a loopback test, wait for the test completion by polling for the object 'testResult'. A value of 'inProgress(3)' will result if the test is still in progress. Once the test is completed, the object 'testResult' will have a value of 'success(2)' if the loopback OAM cell returned to the originator of the test within 5 seconds, if not, a value of 'failed(7)' will result. If the ATM system does not support this type of loopback test, then a value of 'notSupported(4)' will be provided. Other possible values for the 'testResult' object are 'unAbleToRun(5)' and 'aborted(6)'." ::= { atmLoopbackTestTypes 2 } atmLoopbackVpSegment OBJECT-IDENTITY STATUS current DESCRIPTION "This is a loopback test performed on a designated segment of a VP (Virtual Path). To perform this test a segment OAM cell is inserted at one of the segment end-points of the designated VP connection (e.g., at a host) via VCI=3 (the VCI used for VP OAM segment cells), travels across the segment on the designated VP to the device pre-configured as the corresponding segment end-point, and then loops back to the originating segment end-point on the designated VP. Success is achieved if the loopback OAM cell returns to the originating end-point within 5 seconds, otherwise, the test fails. In order to use the atmLoopbackVpSegment test, a segment must be defined by setting up segment end- points using the atmVplEndptSegmentEndPoint object from the atmVplEndptTable. The atmVplEndptSegmentEndPoint is set to isaVpSegmentEndPoint(1) for each segment end-point. Note that this object is by default set to isaVpSegmentEndPoint(1) if the atmVplTable supports one end of a UNI. In such a case, a UNI VP loopback test would be achieved when the atmLoopbackVpSegment test was initiated over the UNI. The manager-station performs a loopback test by making use of the testTable) defined in [10]. In Expires September 1997 [Page 15] draft ATM Test Objects March 1997 order to run this test the object 'testType' in the testTable shall be set to atmLoopbackVpE2e, and the object testTarget points to the row in the atmVplTable in [1] corresponding to the VP designated for the test. Before starting a test, a manager-station must first obtain 'ownership' of the entry in the testTable for the interface to be tested (follow procedure defined in [10]). Once the manager-station obtains ownership, a loopback test for a given interface can be invoked by first setting up parameters necessary for the loopback test (e.g., set the testTarget), and then setting the value of 'testType' in the testTable equal to 'atmLoopbackVpSegment'. This will cause the atmLoopbackVpSegment test to be invoked on the VP with the VPI corresponding to the testTarget. After invoking a loopback test, wait for the test completion by polling for the object 'testResult'. A value of 'inProgress(3)' will result if the test is still in progress. Once the test is completed, the object 'testResult' will have a value of 'success(2)' if the loopback OAM cell returned to the originator of the test within 5 seconds, if not, a value of 'failed(7)' will result. If the ATM system does not support this type of loopback test, then a value of 'notSupported(4)' will be provided. Other possible values for the 'testResult' object are 'unAbleToRun(5)' and 'aborted(6)'." ::= { atmLoopbackTestTypes 3 } atmLoopbackVcSegment OBJECT-IDENTITY STATUS current DESCRIPTION "This is a loopback test performed on a designated segment of a VC (Virtual Channel). To perform this test a segment OAM cell is inserted at one of the segment end-points of the designated VC connection (e.g., at a host) via PTI=4 (the PTI value used for VC OAM segment cells), travels across the segment on the designated VC to the device pre-configured as the corresponding segment end-point, and then loops back to the originating segment end-point on the designated Expires September 1997 [Page 16] draft ATM Test Objects March 1997 VC. Success is achieved if the loopback OAM cell returns to the originating end-point within 5 seconds, otherwise, the test fails. In order to use the atmLoopbackVcSegment test, a segment must be defined by setting up segment end- points using the atmVclEndptSegmentEndPoint object from the atmVclEndptTable. The atmVclEndptSegmentEndPoint is set to isaVcSegmentEndPoint(1) for each segment end-point. Note that this object is by default set to isaVcSegmentEndPoint(1) if the atmVclTable supports one end of a UNI. In such a case, a UNI VC loopback test would be achieved when the atmLoopbackVcSegment test was initiated over the UNI. The manager-station performs a loopback test by making use of the testTable) defined in [10]. In order to run this test the object 'testType' in the testTable shall be set to atmLoopbackVcE2e, and the object testTarget points to the row in the atmVclTable in [1] corresponding to the VC designated for the test. Before starting a test, a manager-station must first obtain 'ownership' of the entry in the testTable for the interface to be tested (follow procedure defined in [10]). Once the manager-station obtains ownership, a loopback test for a given interface can be invoked by first setting up parameters necessary for the loopback test (e.g., set the testTarget), and then setting the value of 'testType' in the testTable equal to 'atmLoopbackVcSegment'. This will cause the atmLoopbackVcSegment test to be invoked on the VC with the VPI/VCI corresponding to the testTarget. After invoking a loopback test, wait for the test completion by polling for the object 'testResult'. A value of 'inProgress(3)' will result if the test is still in progress. Once the test is completed, the object 'testResult' will have a value of 'success(2)' if the loopback OAM cell returned to the originator of the test within 5 seconds, if not, a value of 'failed(7)' will result. If the ATM system does not support this type of loopback test, then a value of 'notSupported(4)' will be provided. Other possible Expires September 1997 [Page 17] draft ATM Test Objects March 1997 values for the 'testResult' object are 'unAbleToRun(5)' and 'aborted(6)'." ::= { atmLoopbackTestTypes 4 } atmLoopbackVpLocationId OBJECT-IDENTITY STATUS current DESCRIPTION "This is a loopback test performed on a portion of a designated VP segment. To perform this test a loopback OAM cell is inserted at a connection point of the designated VP connection (e.g., the end-point or a tandem point) with a value inserted in the Location Identifier ID field of the OAM cell that corresponds to the ATM device where the cell is to be looped back. The loopback cell then travels through the VP connection until it reaches the designated ATM device, where it is looped back to the loopback cell insertion point on the designated VP. Success is achieved if the loopback OAM cell returns to the originating point of insertion within 5 seconds, otherwise, the test fails. The manager-station performs a loopback test by making use of the testTable) defined in [10]. In order to run this test the object 'testType' in the testTable shall be set to atmLoopbackVpE2e.d, where the subidentifier 'd' consists of 16 subidentifiers with each subidentifier corresponding to the value of a subsequent octet of the Loopback Location ID defined in I.610[9] starting with the most significant octet. The object testTarget points to the row in the atmVplTable in [1] corresponding to the VP designated for the test. Before starting a test, a manager-station must first obtain 'ownership' of the entry in the testTable for the interface to be tested (follow procedure defined in [10]). Once the manager-station obtains ownership, a loopback test for a given interface can be invoked by first setting up parameters necessary for the loopback test (e.g., set d to AAAABBBBCCCCDDDD and set the testTarget), and then setting the value of 'testType' in the testTable equal to 'atmLoopbackVpSegment.d'. This will cause the atmLoopbackVpLocationId test to be invoked on the VP with the VPI corresponding to the testTarget and looped back at loopback location ID= Expires September 1997 [Page 18] draft ATM Test Objects March 1997 AAAABBBBCCCCDDDD. After invoking a loopback test, wait for the test completion by polling for the object 'testResult'. A value of 'inProgress(3)' will result if the test is still in progress. Once the test is completed, the object 'testResult' will have a value of 'success(2)' if the loopback OAM cell returned to the originator of the test within 5 seconds, if not, a value of 'failed(7)' will result. If the ATM system does not support this type of loopback test, then a value of 'notSupported(4)' will be provided. Other possible values for the 'testResult' object are 'unAbleToRun(5)' and 'aborted(6)'." ::= { atmLoopbackTestTypes 5 } atmLoopbackVcLocationId OBJECT-IDENTITY STATUS current DESCRIPTION "This is a loopback test performed on a portion of a designated Vc segment. To perform this test a loopback OAM cell is inserted at a connection point of the designated VC connection (e.g., the end-point or a tandem point) with a value inserted in the Location Identifier ID field of the OAM cell that corresponds to the ATM device where the cell is to be looped back. The loopback cell then travels through the VC connection until it reaches the designated ATM device, where it is looped back to the loopback cell insertion point on the designated VC. Success is achieved if the loopback OAM cell returns to the originating point of insertion within 5 seconds, otherwise, the test fails. The manager-station performs a loopback test by making use of the testTable) defined in [10]. In order to run this test the object 'testType' in the testTable shall be set to atmLoopbackVcE2e.d, where the subidentifier 'd' consists of 16 subidentifiers with each subidentifier corresponding to the value of a subsequent octet of the Loopback Location ID defined in I.610[9] starting with the most significant octet. The object testTarget points to the row in the atmVclTable in [1] corresponding to the VC designated for the test. Expires September 1997 [Page 19] draft ATM Test Objects March 1997 Before starting a test, a manager-station must first obtain 'ownership' of the entry in the testTable for the interface to be tested (follow procedure defined in [10]). Once the manager-station obtains ownership, a loopback test for a given interface can be invoked by first setting up parameters necessary for the loopback test (e.g., set d to AAAABBBBCCCCDDDD and set the testTarget), and then setting the value of 'testType' in the testTable equal to 'atmLoopbackVcSegment.d'. This will cause the atmLoopbackVcLocationId test to be invoked on the VC with the VPI/VCI corresponding to the testTarget and looped back at loopback location ID= AAAABBBBCCCCDDDD. After invoking a loopback test, wait for the test completion by polling for the object 'testResult'. A value of 'inProgress(3)' will result if the test is still in progress. Once the test is completed, the object 'testResult' will have a value of 'success(2)' if the loopback OAM cell returned to the originator of the test within 5 seconds, if not, a value of 'failed(7)' will result. If the ATM system does not support this type of loopback test, then a value of 'notSupported(4)' will be provided. Other possible values for the 'testResult' object are 'unAbleToRun(5)' and 'aborted(6)'." ::= { atmLoopbackTestTypes 6 } atmLoopbackVpServcInternal OBJECT-IDENTITY STATUS current DESCRIPTION "This is a loopback test that the manager requests an agent to perform over the managed resource's internal portion of a designated VP (i.e., between the ingress and egress interfaces of the VP connection). The agent is provided with the Ingress VPI, Egress Interface, and Egress VPI in order to run this internal test. This test may be useful in proxy situations where the proxy agent represents a network. Implementations of this test may be specific to the managed resource. One implementation in a managed network may be as follows, the managed network inserts a segment loopback OAM cell at the network internal segment end-point (corresponding to the ingress connection point) for the designated VP connection. The loopback cell then Expires September 1997 [Page 20] draft ATM Test Objects March 1997 travels through the network's portion of the VP connection until it reaches the networks connection point to the egress, where it is looped back to the network's cell insertion point on the designated VP. Success is achieved if the loopback OAM cell returns to the originating internal network segment end-point within 5 seconds, otherwise, the test fails. The manager-station performs a loopback test by making use of the testTable) defined in [10]. In order to run this test the object 'testType' in the testTable shall be set to atmLoopbackVpServcInternal, and the object testTarget points to the row in the atmVpCrossConnectTable in [1] corresponding to the VP designated for the test. Before starting a test, a manager-station must first obtain 'ownership' of the entry in the testTable for the interface to be tested (follow procedure defined in [10]). Once the manager-station obtains ownership, a loopback test for a given interface can be invoked by first setting up parameters necessary for the loopback test (e.g., set the testTarget), and then setting the value of 'testType' in the testTable equal to 'atmLoopbackVpServcInternal'. This will cause the atmLoopbackVpServcInternal test to be invoked on the VP crossconnect with the ingress and egress VPI values corresponding to the testTarget. After invoking a loopback test, wait for the test completion by polling for the object 'testResult'. A value of 'inProgress(3)' will result if the test is still in progress. Once the test is completed, the object 'testResult' will have a value of 'success(2)' if the loopback OAM cell returned to the originator of the test within 5 seconds, if not, a value of 'failed(7)' will result. If the ATM system does not support this type of loopback test, then a value of 'notSupported(4)' will be provided. Other possible values for the 'testResult' object are 'unAbleToRun(5)' and 'aborted(6)'." ::= { atmLoopbackTestTypes 7 } atmLoopbackVcServcInternal OBJECT-IDENTITY STATUS current Expires September 1997 [Page 21] draft ATM Test Objects March 1997 DESCRIPTION "This is a loopback test that the manager requests an agent to perform over the managed resource's internal portion of a designated VC (i.e., between the ingress and egress interfaces of the VC connection). The agent is provided with the Ingress VPI, Ingress VCI, Egress Interface, Egress VPI, and Egress VCI in order to run this internal test. This test may be useful in proxy situations where the proxy agent represents a network. Implementations of this test may be specific to the managed resource. One implemenation in a managed network may be as follows, the managed network inserts a segment loopback OAM cell at the network internal segment end-point (corresponding to the ingress connection point) for the designated VC connection. The loopback cell then travels through the network's portion of the VC connection until it reaches the networks connection point to the egress, where it is looped back to the network's cell insertion point on the designated VC. Success is achieved if the loopback OAM cell returns to the originating internal network segment end-point within 5 seconds, otherwise, the test fails. The manager-station performs a loopback test by making use of the testTable) defined in [10]. In order to run this test the object 'testType' in the testTable shall be set to atmLoopbackVcServcInternal, and the object testTarget points to the row in the atmVcCrossConnectTable in [1] corresponding to the VC designated for the test. Before starting a test, a manager-station must first obtain 'ownership' of the entry in the testTable for the interface to be tested (follow procedure defined in [10]). Once the manager-station obtains ownership, a loopback test for a given interface can be invoked by first setting up parameters necessary for the loopback test (e.g., set the testTarget), and then setting the value of 'testType' in the testTable equal to 'atmLoopbackVcServcInternal'. This will cause the atmLoopbackVcServcInternal test to be invoked on the VC crossconnect with the ingress and egress VPI/VCI values corresponding to the testTarget. Expires September 1997 [Page 22] draft ATM Test Objects March 1997 After invoking a loopback test, wait for the test completion by polling for the object 'testResult'. A value of 'inProgress(3)' will result if the test is still in progress. Once the test is completed, the object 'testResult' will have a value of 'success(2)' if the loopback OAM cell returned to the originator of the test within 5 seconds, if not, a value of 'failed(7)' will result. If the ATM system does not support this type of loopback test, then a value of 'notSupported(4)' will be provided. Other possible values for the 'testResult' object are 'unAbleToRun(5)' and 'aborted(6)'." ::= { atmLoopbackTestTypes 8 } Expires September 1997 [Page 23] draft ATM Test Objects March 1997 -- ************************************************ -- (2) ATM End-Point Group -- This group contains information for interfaces -- supporting ATM Loopback Tests -- This group includes the following: -- 1. ATM VP End-Point Table -- 2. ATM VC End-Point Table atmEndptGroup OBJECT IDENTIFIER::= { atmTESTMIBObjects 2} -- 1. ATM VP End-Point Table atmVplEndptTable OBJECT-TYPE SYNTAX SEQUENCE OF AtmVplEndptEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "End-point Information for each VP." ::= { atmEndptGroup 1 } atmVplEndptEntry OBJECT-TYPE SYNTAX AtmVplEndptEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry with end-point information about the ATM VP." AUGMENTS { atmVplEntry } ::= { atmVplEndptTable 1 } AtmVplEndptEntry ::= SEQUENCE { atmVplEndptSegmentEndPoint INTEGER } atmVplEndptSegmentEndPoint OBJECT-TYPE SYNTAX INTEGER { isaVplSegmentEndPoint(1), notaVplSegmentEndPoint(2) Expires September 1997 [Page 24] draft ATM Test Objects March 1997 } MAX-ACCESS read-create STATUS current DESCRIPTION "An indication of whether or not the VP interface has been configured to represent a VPC Segment End-Point. If the corresponding VP Link is a UNI, the value of this object is permanently set to 1 (isaVplSegmentEndPoint). Otherwise, the default is set to 2 (notaVplSegmentEndPoint)." ::= { atmVplEndptEntry 1 } -- 2. ATM VC End-Point Table atmVclEndptTable OBJECT-TYPE SYNTAX SEQUENCE OF AtmVclEndptEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "End-point Information for each VC." ::= { atmEndptGroup 2 } atmVclEndptEntry OBJECT-TYPE SYNTAX AtmVclEndptEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry with end-point information about the ATM VC." AUGMENTS { atmVclEntry } ::= { atmVclEndptTable 1 } AtmVclEndptEntry ::= SEQUENCE { atmVclEndptSegmentEndPoint INTEGER } atmVclEndptSegmentEndPoint OBJECT-TYPE SYNTAX INTEGER { isaVclSegmentEndPoint(1), notaVclSegmentEndPoint(2) } Expires September 1997 [Page 25] draft ATM Test Objects March 1997 MAX-ACCESS read-create STATUS current DESCRIPTION "An indication of whether or not the VC interface has been configured to represent a VCC Segment End-Point. If the corresponding VC Link is a UNI, the value of this object is permanently set to 1 (isaVclSegmentEndPoint). Otherwise, the default is set to 2 (notaVclSegmentEndPoint)." ::= { atmVclEndptEntry 1 } -- ************************************************ -- Conformance Information atmTESTMIBConformance OBJECT IDENTIFIER ::= {atmTESTMIB 2} atmTESTMIBGroups OBJECT IDENTIFIER ::= {atmTESTMIBConformance 1} atmTESTMIBCompliances OBJECT IDENTIFIER ::= {atmTESTMIBConformance 2} -- Compliance Statements atmTESTMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities which represent ATM interfaces. The compliance statements are used to determine if a particular group or object applies to hosts, networks/switches, or both." MODULE -- this module MANDATORY-GROUPS { atmLoopbackGroup } -- Objects in the ATM Loopback Test Group OBJECT atmLoopbackID MIN-ACCESS read-only DESCRIPTION "Write access is not required. This object is required for ATM systems supporting the atmLoopbackVpLocationID and atmLoopbackVcLocationID Expires September 1997 [Page 26] draft ATM Test Objects March 1997 tests." OBJECT atmVplEndptSegmentEndPoint MIN-ACCESS read-only DESCRIPTION "Write access is not required. This object is mandatory for systems that are supporting ATM loopback tests." OBJECT atmVclEndptSegmentEndPoint MIN-ACCESS read-only DESCRIPTION "Write access is not required. This object is mandatory for systems that are supporting ATM loopback tests." ::= { atmTESTMIBCompliances 1 } -- ********************************************** -- Units of Conformance atmLoopbackGroup OBJECT-GROUP OBJECTS { atmLoopbackID, atmVplEndptSegmentEndPoint, atmVclEndptSegmentEndPoint } STATUS current DESCRIPTION "A collection of objects providing information for Loopback Tests." ::= { atmTESTMIBGroups 1 } END Expires September 1997 [Page 27] draft ATM Test Objects March 1997 7. Acknowledgments This document is a product of the AToMMIB Working Group. The authors would like to acknowledge Dawn Xie for her valuable suggestions for this memo. Expires September 1997 [Page 28] draft ATM Test Objects March 1997 8. References [1] Kaj Tesink, "Definitions of Managed Objects for ATM Management", Internet-Draft, Bellcore, October 1996. [2] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure of Management Information for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1902, January 1996. [3] McCloghrie, K., and M. Rose, Editors, "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", STD 17, RFC 1213, Hughes LAN Systems, Performance Systems International, March 1991. [4] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", RFC 1157, SNMP Research, Performance Systems International, Performance Systems International, MIT Laboratory for Computer Science, May 1990. [5] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol Operations for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, January 1996. [6] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", Internet-Draft, cisco Systems, FTP Software, February 1996. [7] ATM Forum, "ATM User-Network Interface, Version 3.0 (UNI 3.0) Specification, Part I", 1994. [8] ATM Forum, "ATM User-Network Interface, Version 3.1 (UNI 3.1) Specification, Part I", November 1994. [9] ITU-T Recommendation I.610, "Broadband Integrated Service Digital Network (B-ISDN) Operation and Maintenance Principles and Functions", July 1995. [10] McCloghrie, K., M. Greene, and K. Tesink, "Definitions of Managed Objects for System and Interface Testing", Internet-Draft, cisco Systems, Ascom Nexion, Bellcore, November 1996. Expires September 1997 [Page 29] draft ATM Test Objects March 1997 9. Security Considerations Security issues are not discussed in this memo. 10. Authors' Addresses Michael Noto Network Equipment Technologies 800 Saginaw Drive RM 21.1.111 Redwood City, CA 94063 Phone +1 415 569-7134 EMail: mike_noto@net.com Kaj Tesink Bell Communications Research 331 Newman Springs Road P.O. Box 7020 Red Bank, NJ 07701-7020 Phone: (908) 758-5254 EMail: kaj@cc.bellcore.com Expires September 1997 [Page 30] draft ATM Test Objects March 1997 Table of Contents 1 Status of this Memo ................................... 1 2 Introduction .......................................... 2 3 The SNMPv2 Network Management Framework ............... 2 4 Object Definitions .................................... 3 5 Overview .............................................. 3 5.1 Background .......................................... 3 5.2 Important Definitions ............................... 4 5.3 Supported Functions ................................. 5 5.3.1 ATM Testing Support ............................... 5 5.3.1.1 ATM Loopback Testing Group ...................... 5 5.3.1.2 ATM End-Point Group ............................. 9 6 Definitions ........................................... 10 7 Acknowledgments ....................................... 28 8 References ............................................ 29 9 Security Considerations ............................... 30 10 Authors' Addresses ................................... 30 Expires September 1997 [Page 31] --=====================_859419611==_--   Received: from cnri by ietf.org id aa08192; 27 Mar 97 3:33 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa04754; 27 Mar 97 3:33 EST Received: from janus.3com.com (janus.3com.com [129.213.128.99]) by thumper.bellcore.com (8.8.5/8.8.5) with ESMTP id CAA13470 for ; Thu, 27 Mar 1997 02:48:20 -0500 (EST) Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by janus.3com.com (8.8.2/8.8.2) with ESMTP id XAA22573 for ; Wed, 26 Mar 1997 23:47:49 -0800 (PST) Received: from chicago.nsd.3com.com (chicago.nsd.3com.com [129.213.157.11]) by new-york.3com.com (8.8.2/8.8.2) with ESMTP id XAA00893 for ; Wed, 26 Mar 1997 23:46:56 -0800 (PST) Received: from bridge2.NSD.3Com.COM (bridge2.NSD.3Com.COM [129.213.96.3]) by chicago.nsd.3com.com (8.8.2/8.8.2) with ESMTP id XAA09648 for ; Wed, 26 Mar 1997 23:46:49 -0800 (PST) Received: from sutter.NSD.3Com.COM (sutter.NSD.3Com.COM [129.213.48.47]) by bridge2.NSD.3Com.COM (8.8.2/8.8.2) with SMTP id XAA09621 for ; Wed, 26 Mar 1997 23:47:47 -0800 (PST) Received: by sutter.NSD.3Com.COM id AA03359 (5.65c/IDA-1.4.4-910730 for atommib@thumper.bellcore.com); Wed, 26 Mar 1997 23:48:11 -0800 Date: Wed, 26 Mar 1997 23:48:11 -0800 From: Faye Ly Message-Id: <199703270748.AA03359@sutter.NSD.3Com.COM> To: atommib@thumper.bellcore.com Subject: atmVclAddrTable: should switch support this? Hi, During last IETF session, we discussed the pros and cons for implementing atmVclAddrTable on ATM switch/service. I haven't seen any more discussion on the mailing list regarding this issue. Here is a summary and please comment: Support atmVclAddrTable for switch/service and provide an object to turn it on/off. The default action should be off since it is quite expensive for the ATM switch to save all the calling/ called party addresses. The purpose for the ATM switch/service to provide this table to the NMS is for the VC tracing. Thanks. -faye fayely@3com.com (408)764-6576   Received: from cnri by ietf.org id aa08223; 27 Mar 97 3:35 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa04794; 27 Mar 97 3:35 EST Received: from janus.3com.com (janus.3com.com [129.213.128.99]) by thumper.bellcore.com (8.8.5/8.8.5) with ESMTP id DAA13790 for ; Thu, 27 Mar 1997 03:08:17 -0500 (EST) Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by janus.3com.com (8.8.2/8.8.2) with ESMTP id AAA23107 for ; Thu, 27 Mar 1997 00:07:46 -0800 (PST) Received: from chicago.nsd.3com.com (chicago.nsd.3com.com [129.213.157.11]) by new-york.3com.com (8.8.2/8.8.2) with ESMTP id AAA01446 for ; Thu, 27 Mar 1997 00:06:53 -0800 (PST) Received: from bridge2.NSD.3Com.COM (bridge2.NSD.3Com.COM [129.213.96.3]) by chicago.nsd.3com.com (8.8.2/8.8.2) with ESMTP id AAA09880 for ; Thu, 27 Mar 1997 00:06:46 -0800 (PST) Received: from sutter.NSD.3Com.COM (sutter.NSD.3Com.COM [129.213.48.47]) by bridge2.NSD.3Com.COM (8.8.2/8.8.2) with SMTP id AAA09766 for ; Thu, 27 Mar 1997 00:07:44 -0800 (PST) Received: by sutter.NSD.3Com.COM id AA03394 (5.65c/IDA-1.4.4-910730 for atommib@thumper.bellcore.com); Thu, 27 Mar 1997 00:08:07 -0800 Date: Thu, 27 Mar 1997 00:08:07 -0800 From: Faye Ly Message-Id: <199703270808.AA03394@sutter.NSD.3Com.COM> To: atommib@thumper.bellcore.com Subject: ATM Traps: Please comment Content-Type: X-sun-attachment ---------- X-Sun-Data-Type: text X-Sun-Data-Description: text X-Sun-Data-Name: text X-Sun-Content-Lines: 22 Hi, I am trying to ask the oponion from this group regarding ATM traps. There are currently three proposals available regarding ATM PVC/ PVP traps: 1) In draft-ietf-atommib-atm2-txt.08, a more traditional way of doing PVC/PVP traps are proposed. 2) Mickey proposed the Soft PVC approach where the pulling method is preferred. (please see the attatchment 1). 3) Ari Marjamaki proposed Frame Relay/ ATM traps, please see attatchment 2. (12/16/96). I have not known the fourth proposal on this mailing list? Let me know if I have missed anything. Well, we need to decide soon. Any comments? -faye fayely@3com.com (408)764-6576 ---------- X-Sun-Data-Type: mail-file X-Sun-Data-Description: mail-file X-Sun-Data-Name: pvc.trap X-Sun-Encoding-Info: uuencode X-Sun-Content-Lines: 197 begin 600 pvc.trap M1G)O;2!M2!3<&EE9V5L(#QM'0@9F]R(%-E8W1I;VX@.2D*"E1H M92!C=7)R96YT('5P+V1O=VX@49A:6QI;F=05G!L5&%B;&4@ M86YD('1H92!A=&U#=7)R96YT;'E&86EL:6YG4%9C;%1A8FQE"FQI2P@86QL;W=I;F<*=&AE;2!T;R!B92!Q=6EC:VQY(&ED96YT:69I960N M"@I4:&4@871M26YT9E!V8T9A:6QU49A:6QI;F=05F-L M5&%B;&4N"D=E;F5R871I;VX@;V8@=&AE(&%T;4EN=&90=F-&86EL=7)E0H@(" @4U1!5%53(" @(" @(&-U M'@@?0H*27-S=64Z(%!6 M4$P@86YD(%!60TP@9&\@;F]T(&EN8VQU9&4@<&5R;6%N96YT(&QE9W,@;V8@ M4V]F="!05D-S+@H*871M26YT9D-U49A:6QI;F=05G!L'@@?0H*3F]T93H@3F5E9"!T;R!M96YT:6]N(&%T;59P;$-O;FY+:6YD('9A M;'5E(&]F(&!P=F,G(&EN(&]R9&5R('1O"B @(" @(&5X8VQU9&4@5E!,0H@(" @4U1!5%53(" @(" @(&-U MR!A=&U);G1E'1%;G1R>2!X>"!]"@IA=&U);G1F4'9C3F]T:69I8V%T:6]N26YT97)V86P@ M(" @3T)*14-4+5194$4*(" @(%-93E1!6" @(" @("!)3E1%1T52("@Q+BXS M-C P*0H@(" @54Y)5%,@(" @(" @(")S96-O;F1S(@H@(" @34%8+4%#0T53 M4R @(')E860M=W)I=&4*(" @(%-405154R @(" @("!C=7)R96YT"B @("!$ M15-#4DE05$E/3@H@(" @(" @(")4:&4@;6EN:6UU;2!I;G1ER!F86QS92!]"B @(" Z.CT@>R!A M=&U);G1E'1%;G1R>2!X>"!]"@I.;W1E.B!/;F4@<&]SR!A=&TR34E"5')A M<',@,2!]"@IA=&U0=F-4" @("!/0DI%0U0M241%3E1)1DE% M4B Z.CT@>R!A=&U0=F-4'0@:6YCR!A=&U0=F-4" Q('T*"@HT+B!486)L97,@ M3&ES=&EN9R!#=7)R96YT;'D@1F%I;&EN9R!05D-,2!&86EL:6YG(%!64$P@5&%B;&4*"F%T;4-U49A M:6QI;F=05G!L5&%B;&4@(" @3T)*14-4+5194$4*(" @(%-93E1!6" @(" @ M("!315%514Y#12!/1B!!=&U#=7)R96YT;'E&86EL:6YG4%9P;$5N=')Y"B @ M("!-05@M04-#15-3(" @;F]T+6%C8V5S49A:6QI;F=05G!L16YTR!I9DEN9&5X+"!A=&U6<&Q6<&D@?0H@(" @.CH]('L@871M0W5R49A:6QI;F=05G!L M16YT49A:6QI;F=05G!L5&EM95-T86UP(" @(" @5&EM95-T86UP"B @ M(" @(" @(" @(" @('T*"F%T;4-U49A:6QI;F=05G!L5&EM95-T M86UP(" @($]"2D5#5"U465!%"B @("!364Y405@@(" @(" @5&EM95-T86UP M"B @("!-05@M04-#15-3(" @2 Q('T*"@HM+2!#=7)R96YT;'D@ M1F%I;&EN9R!05D-,(%1A8FQE"@IA=&U#=7)R96YT;'E&86EL:6YG4%9C;%1A M8FQE(" @($]"2D5#5"U465!%"B @("!364Y405@@(" @(" @4T51545.0T4@ M3T8@071M0W5R0H@(" @34%8+4%#0T53 M4R @(&YO="UA8V-ER!A=&TR34E"3V)J96-T"!]"@IA=&U#=7)R96YT;'E&86EL M:6YG4%9C;$5N=')Y(" @($]"2D5#5"U465!%"B @("!364Y405@@(" @(" @ M071M0W5R0H@(" @34%8+4%#0T534R @ M(&YO="UA8V-E2!I;B!T:&ES('1A8FQE M(')E<')E"P@ M871M5F-L5G!I+"!A=&U68VQ68VD@?0H@(" @.CH]('L@871M0W5R49A:6QI;F=05F-L M16YT49A:6QI;F=05F-L5&EM95-T86UP(" @(" @5&EM95-T86UP"B @ M(" @(" @(" @(" @('T*"F%T;4-U49A:6QI;F=05F-L5&EM95-T M86UP(" @($]"2D5#5"U465!%"B @("!364Y405@@(" @(" @5&EM95-T86UP M"B @("!-05@M04-#15-3(" @2 Q('T*"@HM+2TM+2TM+2TM+2TM M+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM M+2TM+2TM+2TM+2TM+2T*171H86X@36EC:V5Y(%-P:65G96PL(%!H+D0N"D-I M2!3<&EE9V5L M*0I$871E.B!-;VXL(#$V($1E8R Q.3DV(#(P.C S.C(S("LP,C P("A%150I M"D-C.B!A=&]M;6EB0'1H=6UP97(N8F5L;&-O7!E.B!T97AT"D-O;G1E;G0M3&5N9W1H.B W-3,W"E-T871U M&-L=61E M('!E2!F;W(@82!C;VQL96-T:6]N(&]F('!V M8R!F86EL=7)E2!I M;7!O2!E;F]U9V@@*&DN92X@<&]L;&EN9R!P M97)I;V0@;&5S2!R97-O;'9E9"!I;B!T:&4@;W)I9VEN86P@<')O<&]S86P@8GD@ M=&AE(&1E9FEN:71I;VX@=&AA="!T:&4*5F-L+U9P;$-H86YG92!T2!S97)V:6-E2!397)V:6-E"BTM("AD'0I.@H*9G)!=&U)=V9#;VYN4W1A='5S0VAA M;F=E($Y/5$E&24-!5$E/3BU465!%"B @(" @("!/0DI%0U13('L@(&9R071M M27=F0V]N;D9R4&]R="P@(&9R071M27=F0V]N;D1L8VDL"B @(" @(" @(" @ M(" @(" @(&9R071M27=F0V]N;D%T;5!O2!S=6=G97-T:6]N(&ES M('1O(&QI;FL@=&]G971H97(@=&AE('1W;R!T2!D969I;F5D(&EN($%T;69O2!B M92!A(&=O;V0@:61E82!T;R!I;F-L=61E(&ET(&EN(&%T;0IS=7!P;&5M96YT M86P@;6EB(&1E9FEN:71I;VYS+B!!;F]T:&5R('!O2!O M9B!T:&4@9&5F:6YE9"!A=&T@=')A< IT>7!E(&-O;6)I;F%T:6]N6YT87@I.@H*871M26YT9E1R87!#;VYTPH)"6YO5')A<"@P*2P@"@D)871M26YT9E!V M8T9A:6QU'1%;G1R>2!X>"!]( H*"D%N>2!C;VUM96YT M; Thu, 27 Mar 1997 13:02:41 -0500 (EST) Message-Id: <199703271802.NAA28771@thumper.bellcore.com> Received: from bcarsfba.ott.bnr.ca (actually bcarsfba.bnr.ca) by bcarsde4.localhost; Thu, 27 Mar 1997 12:50:54 -0500 Received: from bnr.ca by bcarsfba.bnr.ca id <23071-0@bcarsfba.bnr.ca>; Thu, 27 Mar 1997 12:52:46 -0500 Date: 27 Mar 1997 11:39 EST Sender: Chunhui Teng To: fayely@3com.com Cc: Nalin Mistry , Robert Holt , Richard Vallee , Shedman Tam , atommib@thumper.bellcore.com From: Chunhui Teng Subject: re:ATM Traps: Please comment Hi all, At first, I tend to agree with Ari Marjamaki. In addition to his proposal, I have some ideas mentioned below. 1. Isn't it a good idea to refine down state for atmVplOperStatus and atmVclOperStatus objects so that there is a state called "lowerLayerDown" just like IFMIB does? It is defined in draft-ietf-ifmib-mib-05.txt: ifOperStatus OBJECT-TYPE SYNTAX INTEGER { up(1), -- ready to pass packets down(2), testing(3), -- in some test mode unknown(4), -- status can not be determined dormant(5), notPresent(6), -- some component is missing lowerLayerDown(7) -- down due to state of -- lower-layer interface(s) } 2. Another trap I can come out my mind is a trap sent when the interface is down and whose varbind includes all VPL/VCLs that have state lowerLayerDown. In this way nms can know immediately that a lower layer was down and which VPL/VCLs were affected while a flood of traps will not happen. But I suspect the varbind would be just too large to be fit in an SNMP trap. (Sorry I did not try to write the ASN.1 definition of this trap, please tell me if you would like to see it) Regards, Chunhui Teng In message "ATM Traps: Please comment", 'fayely@3com.com' writes: >---------- >X-Sun-Data-Type: text >X-Sun-Data-Description: text >X-Sun-Data-Name: text >X-Sun-Content-Lines: 22 > >Hi, > >I am trying to ask the oponion from this group regarding ATM traps. >There are currently three proposals available regarding ATM PVC/ >PVP traps: > >1) In draft-ietf-atommib-atm2-txt.08, a more traditional way of >doing PVC/PVP traps are proposed. > >2) Mickey proposed the Soft PVC approach where the pulling method >is preferred. (please see the attatchment 1). > >3) Ari Marjamaki proposed Frame Relay/ ATM traps, please see >attatchment 2. (12/16/96). > >I have not known the fourth proposal on this mailing list? Let >me know if I have missed anything. Well, we need to decide >soon. Any comments? > >-faye >fayely@3com.com >(408)764-6576 >---------- >X-Sun-Data-Type: mail-file >X-Sun-Data-Description: mail-file >X-Sun-Data-Name: pvc.trap >X-Sun-Encoding-Info: uuencode >X-Sun-Content-Lines: 197 > 382 lines deleted...   Received: from cnri by ietf.org id aa02156; 27 Mar 97 13:55 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa17778; 27 Mar 97 13:55 EST Received: from janus.3com.com (janus.3com.com [129.213.128.99]) by thumper.bellcore.com (8.8.5/8.8.5) with ESMTP id NAA29706 for ; Thu, 27 Mar 1997 13:31:53 -0500 (EST) Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by janus.3com.com (8.8.2/8.8.2) with ESMTP id KAA04260; Thu, 27 Mar 1997 10:29:41 -0800 (PST) Received: from chicago.nsd.3com.com (chicago.nsd.3com.com [129.213.157.11]) by new-york.3com.com (8.8.2/8.8.2) with ESMTP id KAA12808; Thu, 27 Mar 1997 10:28:44 -0800 (PST) Received: from bridge2.NSD.3Com.COM (bridge2.NSD.3Com.COM [129.213.96.3]) by chicago.nsd.3com.com (8.8.2/8.8.2) with ESMTP id KAA20505; Thu, 27 Mar 1997 10:28:42 -0800 (PST) Received: from sutter.NSD.3Com.COM (sutter.NSD.3Com.COM [129.213.48.47]) by bridge2.NSD.3Com.COM (8.8.2/8.8.2) with SMTP id KAA14301; Thu, 27 Mar 1997 10:29:39 -0800 (PST) Received: by sutter.NSD.3Com.COM id AA04201 (5.65c/IDA-1.4.4-910730); Thu, 27 Mar 1997 10:30:00 -0800 Date: Thu, 27 Mar 1997 10:30:00 -0800 From: Faye Ly Message-Id: <199703271830.AA04201@sutter.NSD.3Com.COM> To: fayely@3com.com, cteng@nortel.ca Subject: re:ATM Traps: Please comment Cc: nalin@nortel.ca, rholt@nortel.ca, vallee@nortel.ca, shedman@nortel.ca, atommib@thumper.bellcore.com Chunhui, > > At first, I tend to agree with Ari Marjamaki. > > In addition to his proposal, I have some ideas mentioned below. > > 1. Isn't it a good idea to refine down state for atmVplOperStatus and > atmVclOperStatus objects so that there is a state called "lowerLayerDown" > just like IFMIB does? > > It is defined in draft-ietf-ifmib-mib-05.txt: > > ifOperStatus OBJECT-TYPE > SYNTAX INTEGER { > up(1), -- ready to pass packets > down(2), > testing(3), -- in some test mode > unknown(4), -- status can not be determined > dormant(5), > notPresent(6), -- some component is missing > lowerLayerDown(7) -- down due to state of > -- lower-layer interface(s) > } > Good idea except that the atm2 MIB doesn't require compliance with "draft- ietf-ifmib-mib-05.txt". We can certainly pulls it into the atm2 MIB but I would like to only use it as optionally required since I think most people don't have the support for the ifmib-mib-05 yet. > 2. Another trap I can come out my mind is a trap sent when the interface is down > and whose varbind includes all VPL/VCLs that have state lowerLayerDown. > In this way nms can know immediately that a lower layer was down and which > VPL/VCLs were affected while a flood of traps will not happen. But I suspect > the varbind would be just too large to be fit in an SNMP trap. > (Sorry I did not try to write the ASN.1 definition of this trap, please tell > me if you would like to see it) > Another good idea. And you are right, the varbinds might be too much to fit into on trap PDU. How about the counters Mickey proposed? Do you think they are sufficient? Or if we combine Mickey's counters and a history of all the failures in the accounting MIB will help? Thanks. -faye fayely@3com.com (408)764-6576 > Regards, > > Chunhui Teng > > In message "ATM Traps: Please comment", 'fayely@3com.com' writes: > > >---------- > >X-Sun-Data-Type: text > >X-Sun-Data-Description: text > >X-Sun-Data-Name: text > >X-Sun-Content-Lines: 22 > > > >Hi, > > > >I am trying to ask the oponion from this group regarding ATM traps. > >There are currently three proposals available regarding ATM PVC/ > >PVP traps: > > > >1) In draft-ietf-atommib-atm2-txt.08, a more traditional way of > >doing PVC/PVP traps are proposed. > > > >2) Mickey proposed the Soft PVC approach where the pulling method > >is preferred. (please see the attatchment 1). > > > >3) Ari Marjamaki proposed Frame Relay/ ATM traps, please see > >attatchment 2. (12/16/96). > > > >I have not known the fourth proposal on this mailing list? Let > >me know if I have missed anything. Well, we need to decide > >soon. Any comments? > > > >-faye > >fayely@3com.com > >(408)764-6576 > >---------- > >X-Sun-Data-Type: mail-file > >X-Sun-Data-Description: mail-file > >X-Sun-Data-Name: pvc.trap > >X-Sun-Encoding-Info: uuencode > >X-Sun-Content-Lines: 197 > > > 382 lines deleted... >   Received: from cnri by ietf.org id aa04217; 27 Mar 97 14:37 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa18780; 27 Mar 97 14:37 EST Received: from janus.3com.com (janus.3com.com [129.213.128.99]) by thumper.bellcore.com (8.8.5/8.8.5) with ESMTP id OAA01390 for ; Thu, 27 Mar 1997 14:15:22 -0500 (EST) Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by janus.3com.com (8.8.2/8.8.2) with ESMTP id LAA09511; Thu, 27 Mar 1997 11:14:44 -0800 (PST) Received: from chicago.nsd.3com.com (chicago.nsd.3com.com [129.213.157.11]) by new-york.3com.com (8.8.2/8.8.2) with ESMTP id LAA18209; Thu, 27 Mar 1997 11:13:47 -0800 (PST) Received: from bridge2.NSD.3Com.COM (bridge2.NSD.3Com.COM [129.213.96.3]) by chicago.nsd.3com.com (8.8.2/8.8.2) with ESMTP id LAA22674; Thu, 27 Mar 1997 11:13:45 -0800 (PST) Received: from sutter.NSD.3Com.COM (sutter.NSD.3Com.COM [129.213.48.47]) by bridge2.NSD.3Com.COM (8.8.2/8.8.2) with SMTP id LAA14681; Thu, 27 Mar 1997 11:14:42 -0800 (PST) Received: by sutter.NSD.3Com.COM id AA04277 (5.65c/IDA-1.4.4-910730); Thu, 27 Mar 1997 11:15:04 -0800 Date: Thu, 27 Mar 1997 11:15:04 -0800 From: Faye Ly Message-Id: <199703271915.AA04277@sutter.NSD.3Com.COM> To: atommib@thumper.bellcore.com, dxie@mtgbcs.mt.lucent.com Subject: Re: when the cross-connect's OperStatus is changed to down Dawn, > Atommibers: > > If an interface goes down (say receving some AIS signal), should > the switch also change the OperStatus of the cross-connected > PVCs that goes through that interfacem to down? Does the > OperStatus of the cross-connected PVCs only indicate whether > the "cross-connect" has been programmed into the hardware or > also indicating that no good user cells are passing through the > connection? I would tend to think this is a nature thing for the switch to bring down all the PVCs if the interface is down. I am not sure 1) is worth it or 2) is proper to specify this in the MIB. I alawys thought the MIB is used to describe the behavior of the switch and a honest good MIB probably shouldn't dictate how switch behaves!(- Regards, -faye fayely@3com.com (408)764-6576   Received: from cnri by ietf.org id aa22269; 27 Mar 97 20:21 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa26022; 27 Mar 97 20:21 EST Received: from foxhound.cisco.com (foxhound.cisco.com [171.69.192.161]) by thumper.bellcore.com (8.8.5/8.8.5) with ESMTP id TAA02269 for ; Thu, 27 Mar 1997 19:54:14 -0500 (EST) Received: from cisco.com (localhost [127.0.0.1]) by foxhound.cisco.com (8.8.4-Cisco.1/8.6.5) with ESMTP id QAA09451; Thu, 27 Mar 1997 16:53:42 -0800 (PST) Message-Id: <199703280053.QAA09451@foxhound.cisco.com> To: atommib@thumper.bellcore.com cc: Faye Ly , mspiegel@cisco.com Subject: Re: ATM Traps: Please comment In-reply-to: My message of "Wed, 11 Dec 1996 23:02:56 PST." <199612120702.XAA05279@foxhound.cisco.com> Date: Thu, 27 Mar 1997 16:53:42 -0800 From: Mickey Spiegel My previous proposal on new traps for PVC failures did not sufficiently justify the need to replace the per VC traps with a per interface trap. This message includes the rationale for this change, which is very similar to the rationale for the traps in the ATM Forum Soft PVC MIB (from ATM Forum/96-0592). The current baseline text for the Supplemental AToM MIB (draft-ietf- atommib-atm2-09.txt) specifies that a significant number of SNMP traps can be sent for individual PVCs/PVPs. Traps can be sent upon any change of status of any PVC into or out of the up state. The potential number of traps which can legally be generated by this MIB is too extreme. The following is an extract from Appendix B of RFC 1909 on management philosophy: APPENDIX B - Who Sends Inform-Requests? B.1. Management Philosophy Ever since its beginnings as SGMP, through its definition as SNMPv1, and continuing with the definition of SNMPv2, SNMP has embodied more than just a management protocol and the definitions of MIB objects. Specifically, SNMP has also had a fundamental philosophy of management, consisting of a number of design strategies. These strategies have always included the following: (1) The impact of incorporating an SNMP agent into a system should be minimal, so that both: a) it is feasible to do so even in the smallest/cheapest of systems, and b) the operational role and performance of a system is not compromised by the inclusion of an SNMP agent. This promotes widespread development, which allows ubiquitous deployment of manageable systems. (2) Every system (potentially) incorporates an SNMP agent. In contrast, the number of SNMP managers is limited. Thus, there is a significantly larger number of SNMP agents than SNMP managers. Therefore, overall system development/complexity/cost is optimized if the SNMP agent is allowed to be simple and any required complexity is performed by an SNMP manager. (3) The number of unsolicited messages generated by SNMP agents is minimized. This enables the amount of network management traffic to be controlled by the small number of SNMP managers which are (more) directly controlled by network operators. In fact, this control is considered of greater importance than any additional protocol overhead which might be incurred. Monitoring of network state at any significant level of detail is accomplished primarily by SNMP managers polling for the appropriate information, with the use of unsolicited messages confined to those situations where it is necessary to properly guide an SNMP manager regarding the timing and focus of its polling. This strategy is sometimes referred to as "trap-directed polling". B.2. The Danger of Trap Storms The need for such control over the amount of network management traffic is due to the potential that the SNMP manager receiving an unsolicited message does not want, no longer wants, or already knows of the information contained in the message. This potential is significantly reduced by having the majority of messages be specific requests for information by SNMP managers and responses (to those requests) from SNMP agents. The danger of not having the amount of network management be controlled in this manner is the potential for a "storm" of useless traps. As a simple example of "useless", consider that after a building power outage, every device in the network sends a coldStart trap, even though every SNMP manager and every network operator already knows what happened. For a simple example of "storm", consider the result if each transmitted trap caused the sending of another. The greater the number of problems in the state of the network, the greater the risk of such a storm occurring, especially in the unstructured, heterogeneous environment typical of today's internets. While SNMP philosophy considers the above to be more important than any lack of reliability in unsolicited messages, some users/developers have been wary of using traps because of the use (typically) of an unreliable transport protocol and because traps are not acknowledged. However, following this logic would imply that having acknowledged-traps would make them reliable; of course, this is false since no amount of re- transmission will succeed if the receiver and/or the connectivity to the receiver is down. A SNMP manager cannot just sit and wait and assume the network is fine just because it is not receiving any unsolicited messages. Applying the Management Philosophy to Soft-PVC/PVP Traps In order to avoid "trap storms" (sometimes called "avalanches"), traps cannot be sent for every PVC/PVP failure. When a large group of PVCs/PVPs on a link goes down, it is unacceptable that a trap is generated for each failed PVC/PVP. It is also unacceptable for a trap to be generated for each PVC/PVP when they come back up. An NMS cannot rely on receiving these traps, and thus, cannot rely on receiving a trap in order to keep track of the state of PVCs/ PVPs. (Consider, for example, if an ATM switch's connection to its NMS is via one of these very same PVCs/PVPs). The basic problem here is that the sending of per-connection traps doesn't scale. Given that some per-connection traps are not sent because of the need to limit the avalanche, then it's valuable to include in each trap some information on how many events would have generated traps but for the limit, e.g., define a new MIB object which is a counter of the number of PVC failures, and include this is in the trap's varbind list. Note that because traps can get lost, it is an overall counter of failures, not the number since the last trap. Given the inclusion of this and potentially other similar counters in the trap, then the trap is no longer a per-connection trap, but rather it becomes an indicator of PVC/PVP connectivity problems which can be sent on a periodic basis while the problems persist. The trap can include as many variables as needed to give the current state, and to direct a subsequent search by the NMS (should the NMS be interested) for more info on which PVCs/PVPs have failed. Given that the semantics of the trap become "periodic while the problems persist", then it is valuable to define the minimum number of seconds between traps. The detailed proposal on trap-directed polling for PVC failures follows. Mickey Spiegel Cisco Systems > From: Mickey Spiegel > Message-Id: <199612120702.XAA05279@foxhound.cisco.com> > To: atommib@thumper.bellcore.com > cc: mspiegel > Subject: PVC Traps > Date: Wed, 11 Dec 96 23:02:56 PST > > This message contains a proposal on traps for PVC failures. This differs > significantly from the traps defined in draft-ietf-atommib-atm2-08.txt, > in that it replaces the per VC traps with a per interface trap. This > proposal limits the rate of trap generation according to a configurable > object, thus avoiding the potential for a flood of traps inherent in the > use of per VC traps. This proposal is based on the traps for Soft PVCs > defined in the ATM Forum Soft PVC MIB addendum to the PNNI 1.0 > specification. > > Note that although draft-ietf-atommib-atm2-08.txt did borrow one concept > from the ATM Forum Soft PVC MIB, resulting in the atmTrapThreshold, some > of us feel that this is the least important concept introduced there. > This proposal does not incorporate the atmTrapThreshold, but does > incorporate many of the other concepts introduced in the Soft PVC MIB. > > Issue: Should traps be on a per interface basis or per managed entity basis? > > > 1. Description of Tables, Objects, and Traps for Detection of PVC Failures > (replacement text for Section 9) > > The current up/down status of each permanent VPL or VCL is indicated by > the atmVplOperStatus or atmVclOperStatus object, respectively. Several > tables and objects and one trap are defined in order to help network > managers quickly and efficiently detect changes in the status of > permanent virtual links. Through use of these tables, objects, and > traps, the time consuming and resource intensive task of continuously > polling each row in the entire atmVplTable and atmVclTable can be > avoided. > > The atmIntfPvcFailures counter and the atmIntfCurrentlyFailingPVpls > and atmIntfCurrentlyFailingPVcls gauges provide a quick means of > determining the status of all PVPLs and PVCLs on an interface. The > atmCurrentlyFailingPVplTable and the atmCurrentlyFailingPVclTable > list all of the problematic PVPLs and PVCLs, respectively, allowing > them to be quickly identified. > > The atmIntfPvcFailuresTrap is generated just after a PVPL or PVCL on > a particular interface leaves the `up' operational state. Managers can > then determine which PVPLs and/or PVCLs are failing by reading the > atmCurrentlyFailingPVplTable and the atmCurrentlyFailingPVclTable. > Generation of the atmIntfPvcFailuresTrap is rate limited by suppressing > all traps that would occur within atmIntfPvcNotificationInterval of a > previous trap for the same interface. Managers should continuously > poll the tables and objects mentioned above for at least this amount > of time in order to keep up with the state of the network. > > > 2. New objects for atmInterfaceExtTable > > atmIntfPvcFailures OBJECT-TYPE > SYNTAX Counter32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The number of times the operational status of a > PVPL or PVCL on this interface has gone down." > ::= { atmInterfaceExtEntry xx } > > Issue: PVPL and PVCL do not include permanent legs of Soft PVCs. > > atmIntfCurrentlyFailingPVpls OBJECT-TYPE > SYNTAX Gauge32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The current number of VPLs on this interface for > which there is an active row in the atmVplTable > having an atmVplConnKind value of `pvc' and an > atmVplOperStatus with a value other than `up'." > ::= { atmInterfaceExtEntry xx } > > Note: Need to mention atmVplConnKind value of `pvc' in order to > exclude VPLs used in Soft PVPCs. > > atmIntfCurrentlyFailingPVcls OBJECT-TYPE > SYNTAX Gauge32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The current number of VCLs on this interface for > which there is an active row in the atmVclTable > having an atmVclConnKind value of `pvc' and an > atmVclOperStatus with a value other than `up'." > ::= { atmInterfaceExtEntry xx } > > atmIntfPvcNotificationInterval OBJECT-TYPE > SYNTAX INTEGER (1..3600) > UNITS "seconds" > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "The minimum interval between the sending of > atmIntfPvcFailuresTrap notifications for this > interface." > DEFVAL { 30 } > ::= { atmInterfaceExtEntry xx } > > Issue: Use DEFVAL clause on read-write objects, or use DESCRIPTION? > > atmIntfPvcFailuresTrapEnable OBJECT-TYPE > SYNTAX TruthValue > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "Allows the generation of traps in response to PVCL or > PVPL failures on this interface." > DEFVAL { false } > ::= { atmInterfaceExtEntry xx } > > Note: One possibility is to eliminate the atmIntfPvcFailuresTrapEnable > object and to use the distinguished value zero of the > atmIntfPvcNotificationInterval to disable generation of traps. > > > 3. Trap definition > > -- ATM PVC Traps > > atmPvcTraps OBJECT-IDENTIFIER ::= { atm2MIBTraps 1 } > > atmPvcTrapsPrefix OBJECT-IDENTIFIER ::= { atmPvcTraps 0 } > > atmIntfPvcFailuresTrap NOTIFICATION-TYPE > OBJECTS { ifIndex, atmIntfPvcFailures, > atmIntfCurrentlyFailingPVpls, > atmIntfCurrentlyFailingPVcls } > STATUS current > DESCRIPTION > "A notification indicating that one or more PVPLs or > PVCLs on this interface has failed since the last > atmPvcFailuresTrap was sent. If this trap has not > been sent for the last atmIntfPvcNotificationInterval, > then it will be sent on the next increment of > atmIntfPvcFailures." > ::= { atmPvcTrapsPrefix 1 } > > > 4. Tables Listing Currently Failing PVCLs and PVPLs > > -- Currently Failing PVPL Table > > atmCurrentlyFailingPVplTable OBJECT-TYPE > SYNTAX SEQUENCE OF AtmCurrentlyFailingPVplEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "A table indicating all VPLs for which there is an > active row in the atmVplTable having an atmVplConnKind > value of `pvc' and an atmVplOperStatus with a value > other than `up'." > ::= { atm2MIBObjects xx } > > atmCurrentlyFailingPVplEntry OBJECT-TYPE > SYNTAX AtmCurrentlyFailingPVplEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "Each entry in this table represents a VPL for which > the atmVplRowStatus is `active', the atmVplConnKind is > `pvc', and the atmVplOperStatus is other than `up'." > INDEX { ifIndex, atmVplVpi } > ::= { atmCurrentlyFailingPVplTable 1 } > > AtmCurrentlyFailingPVplEntry ::= > SEQUENCE { > atmCurrentlyFailingPVplTimeStamp TimeStamp > } > > atmCurrentlyFailingPVplTimeStamp OBJECT-TYPE > SYNTAX TimeStamp > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The time at which this PVPL began to fail." > ::= { atmCurrentlyFailingPVplEntry 1 } > > > -- Currently Failing PVCL Table > > atmCurrentlyFailingPVclTable OBJECT-TYPE > SYNTAX SEQUENCE OF AtmCurrentlyFailingPVclEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "A table indicating all VCLs for which there is an > active row in the atmVclTable having an atmVclConnKind > value of `pvc' and an atmVclOperStatus with a value > other than `up'." > ::= { atm2MIBObjects xx } > > atmCurrentlyFailingPVclEntry OBJECT-TYPE > SYNTAX AtmCurrentlyFailingPVclEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "Each entry in this table represents a VCL for which > the atmVclRowStatus is `active', the atmVclConnKind is > `pvc', and the atmVclOperStatus is other than `up'." > INDEX { ifIndex, atmVclVpi, atmVclVci } > ::= { atmCurrentlyFailingPVclTable 1 } > > AtmCurrentlyFailingPVclEntry ::= > SEQUENCE { > atmCurrentlyFailingPVclTimeStamp TimeStamp > } > > atmCurrentlyFailingPVclTimeStamp OBJECT-TYPE > SYNTAX TimeStamp > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The time at which this PVCL began to fail." > ::= { atmCurrentlyFailingPVclEntry 1 } > > > ------------------------------------------------------------------------ > Ethan Mickey Spiegel, Ph.D. > Cisco Systems Phone: (408)526-6408 > 170 W. Tasman Drive Fax: (408)526-6488 > San Jose, CA 95134-1706 mspiegel@cisco.com > ------------------------------------------------------------------------   Received: from cnri by ietf.org id aa22619; 27 Mar 97 20:44 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa26451; 27 Mar 97 20:44 EST Received: from foxhound.cisco.com (foxhound.cisco.com [171.69.192.161]) by thumper.bellcore.com (8.8.5/8.8.5) with ESMTP id UAA02654 for ; Thu, 27 Mar 1997 20:16:14 -0500 (EST) Received: from cisco.com (localhost [127.0.0.1]) by foxhound.cisco.com (8.8.4-Cisco.1/8.6.5) with ESMTP id RAA09907; Thu, 27 Mar 1997 17:12:22 -0800 (PST) Message-Id: <199703280112.RAA09907@foxhound.cisco.com> To: Ari Marjamaki cc: atommib@thumper.bellcore.com, Ari.Marjamaki@tele.fi Subject: Re: PVC Traps In-reply-to: Your message of "Mon, 16 Dec 1996 20:03:23 +0200." <199612161803.UAA06615@kuutti.dat.tele.fi> Date: Thu, 27 Mar 1997 17:12:21 -0800 From: Mickey Spiegel My general comments on per VC traps were contained in my previous message. A few specific responses to Ari's comments are included in this reply. > > This message contains a proposal on traps for PVC failures. This differs > > significantly from the traps defined in draft-ietf-atommib-atm2-08.txt, > > in that it replaces the per VC traps with a per interface trap. This > > proposal limits the rate of trap generation according to a configurable > > object, thus avoiding the potential for a flood of traps inherent in the > > use of per VC traps. This proposal is based on the traps for Soft PVCs > > defined in the ATM Forum Soft PVC MIB addendum to the PNNI 1.0 > > specification. > > Unfortunately I disagree about the idea of replacing per VC traps > (i.e. atmPvplChange and atmPvclChange) with a per interface trap > (i.e. atmIntfPvcFailuresTrap). > > I don't understand how it would be possible to exclude per vc traps > when this new proposal lacks the same qualities that were in the > original atm traps proposal (draft-ietf-atommib-atm2-08.txt). In my > opinion the original proposal was very well defined and very useful > and therefore I suggest that it should also be included in the > supplemental ATM MIB as an alternative choice for atmIntfPvcFailuresTraps. While per VC notification of status changes may be desirable, unfortunately it does not always work. See my previous message for details. > The new trap is defined only for a collection of pvc failures, but > individual Pvpl/Pvcl status change traps are also needed, because they > provide more detailed information as can be seen from the table below. > > required information atmIntfPvcFailures atmPvcl/PvplChange > ----------------------------------------------------------------------------- > identify Pvcl/Pvpl vpi/vci has to be polled available in trap > time, when Pvcl/Pvpl went down has to be polled available in trap > time, when Pvcl/Pvpl came up NOT AVAILABLE available in trap > Pvcl/Pvpl downtime NOT AVAILABLE countable from traps > > It should also be noted, that if the failure is a short one (e.g. less > than 10 sec), there is a risk, that the failing connection can not be > identified at all by polling, because the connection might be back up > again, before the nms had time to poll the atmCurrentlyFailingPVplTable > and atmCurrentlyFailingPVclTable. > > In real life networks, these short failures are very common (e.g. time > to reroute Soft pvcs might be about 6 seconds). As atm service > provider we must be able to record also short failures for our own > network analysis and customer reporting purposes. We are also > committed to forward individual connection failure traps to our > customer's nms and provide connection failure/availability reporting, > when customers so request. > > So it is very important for us, that the vcl/vpl state change > information (including vpi/vci and down/up state) is available using > traps only without the need to do any extra polling, since polling may > loose information about short failures and does not scale well in > large networks. It is not possible to poll atmCurrentlyFailingPV*lTables > frequently enough (i.e. polling period less than 10 sec) to identify > all the failing connections. You express a desire to record state changes of PVCs/PVPs. All agree that some form of traps are needed to monitor PVCs/PVPs. It does not follow that trap notifications and management recording are the proper mechanisms to achieve your goal. Note that traps are not reliable. I guess your goals might be more easily achieved, in a robust and scalable manner, through extensions to the ATM accounting MIB. > I also disagree about the traps flood issue problem, because it was > already resolved in the original proposal by the definition that the > Vcl/VplChange trap will not be sent, if the cause of the status change > is a change in status of the underlaying interface layer(s). This > method is used in some other IETF MIBs, so it should be usable for atm > connections too ? It is dangerous for us to presume that we can predict all cases where large numbers of PVCs/PVPs on an interface go up or down. The solution proposed for the Soft PVC MIB is more robust and scalable, regardless of the situation. > For example the MIBs below provide connection status change traps for > FrameRelay services and atm/fr iwf. In my opinion, for compatible > reasons there should also be atm connection status change traps defined > (i.e. atmPvplChange and atmPvclChange). > > -- Definitions of Managed Objects for Frame Relay Service > -- (draft-ieft-frnetmib-frs-mib-00.txt): > > -- Frame Relay Network Service TRAPS > > frPVCConnectStatusChange NOTIFICATION-TYPE > OBJECTS { frPVCConnectIndex, > frPVCConnectLowIfIndex, > frPVCConnectLowDLCIIndex, > frPVCConnectHighIfIndex, > frPVCConnectHighDLCIIndex, > frPVCConnectL2hOperStatus, > frPVCConnectH2lOperStatus, > frPVCEndptRcvdSigStatus, > frPVCEndptRcvdSigStatus } > STATUS current > DESCRIPTION > "This trap indicates that the indicated PVC has > changed state. This trap is not sent if an FR-UNI > changes state; a linkDown or linkUp trap should be > sent instead. The first instance of > frPVCEndptRcvdSigStatus is for the endpoint with > LowIfIndex, LowDLCIIndex. The second instance of > frPVCEndptRcvdSigStatus is for the endpoint with > HighIfIndex, HighDLCIIndex" > ::= { frnetservTraps 1 } > > > -- Managed Objects for Monitoring and Controlling the Frame Relay/ATM > -- Service Interworking Function (draft-ietf-frnetmib-atmiwf-00.txt): > > frAtmIwfConnStatusChange NOTIFICATION-TYPE > OBJECTS { frAtmIwfConnFrPort, frAtmIwfConnDlci, > frAtmIwfConnAtmPort, frAtmIwfConnVpi, frAtmIwfConnVci, > frAtmIwfConnAdminStatus, frAtmIwfConnOperStatus > } > STATUS current > DESCRIPTION > "An indication that the status of this interworking > connection has changed." > ::= { frAtmIwfNotifyPrefix 1 } > > > So my suggestion is to link together the two trap proposals and include all > current three traps (i.e. atmIntfPvcFailuresTrap, atmPvplChange and > atmPvclChange) in the atm supplemental mib and let the user > (i.e. network manager or service provider) decide which mechanism and > combination of traps is best suited for his/her purposes. > > I have also some proposals for changes in the original trap proposal: > > - trap control objects (atmPvplTrapControl and atmPvclTrapControl) > should be per interface and the default value should be trap > generation disabled i.e. noTrap. > > - it should be mentioned in the description of the traps, that also > vcls/vpls with AtmConnKind spvcInitiator(4) and spvcTarget(5) are > included in atmPvplChange and atmPvclChange traps. This is very > important, since we must also be able to identify when a Soft > Pvcc/Pvpc has been cleared, failed, restarted, rerouted, gone down and > came up. Since Soft pvc state change trap or equivalent (i.e. spvc > down/up) is not currently defined in Atmforum's Soft PVC MIB > (af-pnni-0066.0000), it may be a good idea to include it in atm > supplemental mib definitions. Another possibility would be to define > SoftPvcStateChange trap in af-pnni-0066.0000, but I don't know if that > is realistic anymore, when the specification is already approved. Again, I believe your goals can be met in a robust and scalable manner by using the existing Soft PVC MIB traps plus extensions to the ATM Accounting MIB. Per VC traps are neither robust nor scalable. > - it should also be possible to define only one atmTrapControl object, > that allows the network manager to choose any of the defined atm trap > type combinations per interface e.g. something like (not sure about > the syntax): > > atmIntfTrapControl OBJECT-TYPE > SYNTAX BITS { > noTrap(0), > atmIntfPvcFailures(1), > atmPvclChange(2), > atmPvplChange(3) } > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "Allows the generation of traps in response to > PVCL or PVPL failures atmIntfPvcFailures(1), > PVCL status change atmPvclChange(2) and > PVPL status change atmPvplChange(3) > on this interface. > Default is no atm traps noTrap(0)." > DEFVAL {noTrap} > ::= {atmInterfaceExtEntry xx } > > > Any comments are wellcome, thanks. > > Regards, > > Ari > > -- > Ari.Marjamaki@tele.fi tel. +358 (0)2040 72247 > Telecom Finland Ltd. fax. +358 (0)2040 72669 > P.O. BOX 228 > SF-33101 Tampere, Finland Mickey Spiegel Cisco Systems   Received: from cnri by ietf.org id aa11139; 28 Mar 97 9:15 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa09643; 28 Mar 97 9:15 EST Received: from cbgw2.lucent.com (cbgw2.lucent.com [192.20.239.134]) by thumper.bellcore.com (8.8.5/8.8.5) with SMTP id IAA15548 for ; Fri, 28 Mar 1997 08:49:49 -0500 (EST) Cc: nalin@nortel.ca, rholt@nortel.ca, vallee@nortel.ca, shedman@nortel.ca, atommib@thumper.bellcore.com Received: from mtgbcs.mt.lucent.com by cbig2.firewall.lucent.com (SMI-8.6/EMS-L sol2) id IAA19032; Fri, 28 Mar 1997 08:48:29 -0500 From: dxie@mtgbcs.mt.lucent.com Received: from mtpcs52-102 by mtgbcs.mt.lucent.com (5.0/EMS-L sol2) id AA19343; Fri, 28 Mar 1997 08:50:43 -0500 Message-Id: <970328085312.ZM2839@mtpcs52-102> Date: Fri, 28 Mar 1997 08:53:02 -0400 In-Reply-To: Faye Ly "re:ATM Traps: Please comment" (Mar 27, 10:30am) References: <199703271830.AA04201@sutter.NSD.3Com.COM> X-Mailer: Z-Mail 4.0 (4.0.0 Aug 21 1995) To: Faye Ly , cteng@nortel.ca Subject: Re: re:ATM Traps: Please comment Original-Cc: nalin@nortel.ca, rholt@nortel.ca, vallee@nortel.ca, shedman@nortel.ca, atommib@thumper.bellcore.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Mar 27, 10:30am, Faye Ly wrote: > Subject: re:ATM Traps: Please comment > > Chunhui, > > > > > At first, I tend to agree with Ari Marjamaki. > > > > In addition to his proposal, I have some ideas mentioned below. > > > > 1. Isn't it a good idea to refine down state for atmVplOperStatus and > > atmVclOperStatus objects so that there is a state called "lowerLayerDown" > > just like IFMIB does? > > > > It is defined in draft-ietf-ifmib-mib-05.txt: > > > > ifOperStatus OBJECT-TYPE > > SYNTAX INTEGER { > > up(1), -- ready to pass packets > > down(2), > > testing(3), -- in some test mode > > unknown(4), -- status can not be determined > > dormant(5), > > notPresent(6), -- some component is missing > > lowerLayerDown(7) -- down due to state of > > -- lower-layer interface(s) > > } > > > > Good idea except that the atm2 MIB doesn't require compliance with "draft- > ietf-ifmib-mib-05.txt". We can certainly pulls it into the atm2 MIB but > I would like to only use it as optionally required since I think most > people don't have the support for the ifmib-mib-05 yet. However, if we add "lowerLayerDown", then do we need to add "downDueToAIS", or "downDueToRDI", or "downDueToOtherReason...". I was wondering whether it is necessary to list the fail cause in the object, since NMS should be able to find out the cause of failure by looking at other objects, such as associated ifOperStatus. -- Dawn Xie > > > 2. Another trap I can come out my mind is a trap sent when the interface is down > > and whose varbind includes all VPL/VCLs that have state lowerLayerDown. > > In this way nms can know immediately that a lower layer was down and which > > VPL/VCLs were affected while a flood of traps will not happen. But I suspect > > the varbind would be just too large to be fit in an SNMP trap. > > (Sorry I did not try to write the ASN.1 definition of this trap, please tell > > me if you would like to see it) > > > > Another good idea. And you are right, the varbinds might be too much to > fit into on trap PDU. How about the counters Mickey proposed? Do you > think they are sufficient? Or if we combine Mickey's counters and a > history of all the failures in the accounting MIB will help? > > Thanks. > > -faye > fayely@3com.com > (408)764-6576 > > > Regards, > > > > Chunhui Teng > > > > In message "ATM Traps: Please comment", 'fayely@3com.com' writes: > > > > >---------- > > >X-Sun-Data-Type: text > > >X-Sun-Data-Description: text > > >X-Sun-Data-Name: text > > >X-Sun-Content-Lines: 22 > > > > > >Hi, > > > > > >I am trying to ask the oponion from this group regarding ATM traps. > > >There are currently three proposals available regarding ATM PVC/ > > >PVP traps: > > > > > >1) In draft-ietf-atommib-atm2-txt.08, a more traditional way of > > >doing PVC/PVP traps are proposed. > > > > > >2) Mickey proposed the Soft PVC approach where the pulling method > > >is preferred. (please see the attatchment 1). > > > > > >3) Ari Marjamaki proposed Frame Relay/ ATM traps, please see > > >attatchment 2. (12/16/96). > > > > > >I have not known the fourth proposal on this mailing list? Let > > >me know if I have missed anything. Well, we need to decide > > >soon. Any comments? > > > > > >-faye > > >fayely@3com.com > > >(408)764-6576 > > >---------- > > >X-Sun-Data-Type: mail-file > > >X-Sun-Data-Description: mail-file > > >X-Sun-Data-Name: pvc.trap > > >X-Sun-Encoding-Info: uuencode > > >X-Sun-Content-Lines: 197 > > > > > 382 lines deleted... > > > > >-- End of excerpt from Faye Ly   Received: from ietf.org by ietf.org id aa18239; 28 Mar 97 10:24 EST Received: from ietf.ietf.org by ietf.org id aa18089; 28 Mar 97 10:23 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: atommib@thumper.bellcore.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-atommib-test-02.txt Date: Fri, 28 Mar 1997 10:23:48 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9703281023.aa18089@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the AToM MIB Working Group of the IETF. Title : Definitions of Tests for ATM Management Author(s) : M. Noto, K. Tesink Filename : draft-ietf-atommib-test-02.txt Pages : 31 Date : 03/26/1997 This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for managing ATM-based interfaces, devices, networks and services in addition to those defined in the ATM MIB [1], to provide additional support for the management of ATM Loopback Tests. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-atommib-test-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-atommib-test-02.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: ftp.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-atommib-test-02.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970327123537.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-atommib-test-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-atommib-test-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970327123537.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from cnri by ietf.org id aa10714; 28 Mar 97 15:58 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa19477; 28 Mar 97 15:58 EST Received: from VNET.IBM.COM (vnet.ibm.com [199.171.26.4]) by thumper.bellcore.com (8.8.5/8.8.5) with SMTP id PAA29057 for ; Fri, 28 Mar 1997 15:33:09 -0500 (EST) Message-Id: <199703282033.PAA29057@thumper.bellcore.com> Received: from RALVM12 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 7322; Fri, 28 Mar 97 15:33:04 EST Date: Fri, 28 Mar 97 15:05:57 EST From: kennethw@vnet.ibm.com To: kaj@joker.bellcore.com cc: atommib@thumper.bellcore.com, ion@nexen.com Subject: AtmAddr in atm2tc Kaj, In the IPOA MIB I've ended up with the following textual conventions: IpoaAtmAddrKind ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Defines the format of a ATM Physical Address, IpoaAtmAddr objects, as follows: none(1) No ATM Address specified. aesa(2) Structure 1, 20 octet ATM Forum ATM Address encoded as an NSAP form ATM EndSystem Address (AESA) bcdE164(3) Structure 2,(usually 9 octet) BCD encoded E.164 address. nativeE164(4) Structure 2, (usually 15 octet) native encoded E.164 address. bcdE164Aesa(5) Structure 3, BCD encoded E.164 address with a 20 octet ATM Forum ATM Address encoded as an NSAP form ATM EndSystem Address (AESA). nativeE164Aesa(6) Structure 3, native encoded E.164 address with a 20 octet ATM Forum ATM Address encoded as an NSAP form ATM EndSystem Address (AESA). An E.164 encoded address is usually 9 octets if BCD encoded and 15 octets if native encoded. The actually length of a E.164 address can be inferred from the number of octets for a IpoaAtmAddr object and a corresponding IpoaAtmAddrKind object." SYNTAX INTEGER { none(1), aesa(2), bcdE164(3), nativeE164(4), bcdE164Aesa(5), nativeE164Aesa(6) } IpoaAtmAddr ::= TEXTUAL-CONVENTION DISPLAY-HINT "1x" STATUS current DESCRIPTION "The ATM address used by the network entity. The address type can be determined from accessing a corresponding IpoaAtmAddrKind object. An implementation may choose to represent a E.164 address in either native or BCD encoding." There was some discussion on adding a length field but I don't think that this is necessary give the new type textual convention that will be used to create type objects for each AtmAddr object in the IPOA MIB. If at all possible I would like to see the above considered for inclusion in atm2tc instead of defining it uniquely to the IPOA MIB. Thanks, Ken   Received: from cnri by ietf.org id aa12162; 28 Mar 97 16:18 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa19941; 28 Mar 97 16:18 EST Received: from tbird.cc.bellcore.com (tbird.cc.bellcore.com [128.96.96.114]) by thumper.bellcore.com (8.8.5/8.8.5) with SMTP id PAA29886 for ; Fri, 28 Mar 1997 15:57:26 -0500 (EST) Received: from joker (joker.bellcore.com) by tbird.cc.bellcore.com with SMTP id AA02924 (5.67b/IDA-1.5 for ); Fri, 28 Mar 1997 15:57:11 -0500 Received: from nv-ktesink.cc.bellcore.com by joker (4.1/4.7) id AA07973; Fri, 28 Mar 97 15:59:16 EST Date: Fri, 28 Mar 97 15:59:16 EST X-Station-Sent-From: joker.bellcore.com Message-Id: <3.0.16.19970328155639.2a3fbd00@joker.bellcore.com> X-Sender: kaj@joker.bellcore.com X-Mailer: Windows Eudora Pro Version 3.0 (16) To: atommib@thumper.bellcore.com From: Kaj Tesink Subject: agenda ietf Cc: kaj@joker.bellcore.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" hi all, you may have noticed that the atommib wg will have only one meeting slot at the next ietf. the rationale is that we have wrapped up several specs already and should wrap up the supplemental atm mib. faye has sent out an issues list a while ago; not too many comments resulted so i hope this is an indication that we can indeed wrapup quickly :-). the working assumption on the suppl atm mib will be that unresolved issues will cause the assocciated function to be dropped from the mib. in this one slot we need to cover the following: 1 wrapup suppl atm mib 2 test mib and atm test mib 3 mib for ATM Performance History Data Based on 15 Minute Intervals 4 any requirements for a supplemental sonet/sdh mib a la the other supplemental trunk mibs a full plate indeed. my assumption is that most time will be spend on items 1 and 4. please come prepared! kaj _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ _/ _/ _/ Kaj Tesink _/ _/ Bellcore _/ _/ - Emerging Networks vmail (908) 758-5254 _/ _/ 331 Newman Springs Rd. email kaj@cc.bellcore.com _/ _/ Red Bank, NJ 07701 faxmail (908) 758-4177 _/ _/ _/ _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/   Received: from cnri by ietf.org id aa18467; 28 Mar 97 18:15 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa22342; 28 Mar 97 18:15 EST Received: from foxhound.cisco.com (foxhound.cisco.com [171.69.192.161]) by thumper.bellcore.com (8.8.5/8.8.5) with ESMTP id RAA03483 for ; Fri, 28 Mar 1997 17:50:41 -0500 (EST) Received: from cisco.com (localhost [127.0.0.1]) by foxhound.cisco.com (8.8.4-Cisco.1/8.6.5) with ESMTP id OAA01909; Fri, 28 Mar 1997 14:46:47 -0800 (PST) Message-Id: <199703282246.OAA01909@foxhound.cisco.com> To: kennethw@vnet.ibm.com cc: kaj@joker.bellcore.com, atommib@thumper.bellcore.com, ion@nexen.com Subject: Re: AtmAddr in atm2tc In-reply-to: Your message of "Fri, 28 Mar 1997 15:05:57 EST." <199703282033.PAA29057@thumper.bellcore.com> Date: Fri, 28 Mar 1997 14:46:47 -0800 From: Mickey Spiegel > In the IPOA MIB I've ended up with the following textual conventions: I see no need for either textual convention. Most of this information can be obtained from the existing AtmAddr textual convention in the atm2TC MIB, and the rest is not meaningful. Moreover, there is nothing specific to IPOA in these textual conventions, these are normal ATM addresses. > IpoaAtmAddrKind ::= TEXTUAL-CONVENTION > STATUS current > DESCRIPTION > "Defines the format of a ATM Physical Address, > IpoaAtmAddr objects, as follows: > > none(1) No ATM Address specified. AtmAddr with length 0. > aesa(2) Structure 1, 20 octet ATM Forum > ATM Address encoded as an NSAP form > ATM EndSystem Address (AESA) AtmAddr with length 20. > bcdE164(3) Structure 2,(usually 9 octet) BCD encoded > E.164 address. AtmAddr with length 8. > nativeE164(4) Structure 2, (usually 15 octet) native > encoded E.164 address. Not available in AtmAddr textual convention, but why do we need two different representations of the same thing? Both bcdE164 and nativeE164 represent the same thing, a native E.164 address. No matter which kind is used, signalling will transmit it as IA5 characters. > bcdE164Aesa(5) Structure 3, BCD encoded E.164 > address with a 20 octet ATM Forum > ATM Address encoded as an NSAP form ATM > EndSystem Address (AESA). This is the same as aesa (AtmAddr with length 20), with the first byte equal to 0x45. > nativeE164Aesa(6) Structure 3, native encoded > E.164 address with a 20 octet ATM Forum > ATM Address encoded as an NSAP form ATM > EndSystem Address (AESA). No such address type exists. E.164 AESAs must have the E.164 address component coded in BCD. > An E.164 encoded address is usually 9 octets if BCD encoded > and 15 octets if native encoded. The actually length of a > E.164 address can be inferred from the number of octets > for a IpoaAtmAddr object and a corresponding > IpoaAtmAddrKind object." > SYNTAX INTEGER { > none(1), > aesa(2), > bcdE164(3), > nativeE164(4), > bcdE164Aesa(5), > nativeE164Aesa(6) > } > > IpoaAtmAddr ::= TEXTUAL-CONVENTION > DISPLAY-HINT "1x" > STATUS current > DESCRIPTION > "The ATM address used by the network entity. > The address type can be determined from > accessing a corresponding IpoaAtmAddrKind object. > > An implementation may choose to represent a > E.164 address in either native or BCD encoding." SYNTAX ? > There was some discussion on adding a length field but I don't > think that this is necessary give the new type textual convention > that will be used to create type objects for each AtmAddr object > in the IPOA MIB. > > If at all possible I would like to see the above considered for > inclusion in atm2tc instead of defining it uniquely to the IPOA MIB. > > Thanks, Ken Mickey Spiegel Cisco Systems   Received: from cnri by ietf.org id aa19098; 28 Mar 97 18:32 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa22580; 28 Mar 97 18:32 EST Received: from jennie.bellcore.com (jennie.bellcore.com [192.4.15.79]) by thumper.bellcore.com (8.8.5/8.8.5) with SMTP id SAA04277 for ; Fri, 28 Mar 1997 18:08:49 -0500 (EST) Received: from bellcore.com (localhost [127.0.0.1]) by jennie.bellcore.com (8.6.9/8.6.10) with ESMTP id SAA09038; Fri, 28 Mar 1997 18:08:42 -0500 Message-Id: <199703282308.SAA09038@jennie.bellcore.com> To: Mickey Spiegel cc: atommib@thumper.bellcore.com, ion@nexen.com, gja@bellcore.com Subject: Re: AtmAddr in atm2tc In-reply-to: Your message of Fri, 28 Mar 1997 14:46:47 -0800. <199703282246.OAA01909@foxhound.cisco.com> Date: Fri, 28 Mar 1997 18:08:40 -0500 From: Grenville Armitage [..] >>> bcdE164Aesa(5) Structure 3, BCD encoded E.164 >>> address with a 20 octet ATM Forum >>> ATM Address encoded as an NSAP form ATM >>> EndSystem Address (AESA). >> >>This is the same as aesa (AtmAddr with length 20), with the first byte >>equal to 0x45. >> >>> nativeE164Aesa(6) Structure 3, native encoded >>> E.164 address with a 20 octet ATM Forum >>> ATM Address encoded as an NSAP form ATM >>> EndSystem Address (AESA). >> >>No such address type exists. E.164 AESAs must have the E.164 address >>component coded in BCD. Not sure whether it is the thread or the spec that you haven't read, but there certainly _is_ an allowed address format where the main ATM address is E.164 but has an associated AESA 'subaddress'. In both cases above you missed the point. (Or are you just obliquely trying to point out to the original author that there's an entirely different MIB element dedicated to subaddresses? If that's the case, and I'm no MIB expert, just say it.) gja   Received: from cnri by ietf.org id aa19868; 28 Mar 97 18:50 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa22948; 28 Mar 97 18:50 EST Received: from foxhound.cisco.com (foxhound.cisco.com [171.69.192.161]) by thumper.bellcore.com (8.8.5/8.8.5) with ESMTP id SAA04853 for ; Fri, 28 Mar 1997 18:30:28 -0500 (EST) Received: from cisco.com (localhost [127.0.0.1]) by foxhound.cisco.com (8.8.4-Cisco.1/8.6.5) with ESMTP id PAA03027; Fri, 28 Mar 1997 15:29:56 -0800 (PST) Message-Id: <199703282329.PAA03027@foxhound.cisco.com> To: Grenville Armitage cc: atommib@thumper.bellcore.com, ion@nexen.com Subject: Re: AtmAddr in atm2tc In-reply-to: Your message of "Fri, 28 Mar 1997 18:08:40 EST." <199703282308.SAA09038@jennie.bellcore.com> Date: Fri, 28 Mar 1997 15:29:55 -0800 From: Mickey Spiegel > > [..] > >>> bcdE164Aesa(5) Structure 3, BCD encoded E.164 > >>> address with a 20 octet ATM Forum > >>> ATM Address encoded as an NSAP form ATM > >>> EndSystem Address (AESA). > >> > >>This is the same as aesa (AtmAddr with length 20), with the first byte > >>equal to 0x45. > >> > >>> nativeE164Aesa(6) Structure 3, native encoded > >>> E.164 address with a 20 octet ATM Forum > >>> ATM Address encoded as an NSAP form ATM > >>> EndSystem Address (AESA). > >> > >>No such address type exists. E.164 AESAs must have the E.164 address > >>component coded in BCD. > > Not sure whether it is the thread or the spec that you haven't > read, but there certainly _is_ an allowed address format where > the main ATM address is E.164 but has an associated AESA 'subaddress'. > In both cases above you missed the point. I didn't see the word 'subaddress' in these descriptions so I was not aware that this 'address' also includes the subaddress. I do not see why you would use one object for both the main address and the subaddress. Wouldn't it be cleaner to use two separate objects? If you did use one object for both address and subaddress, the description would have to clarify the order. Moreover, if you follow the ATM Forum IAN working group, the current use of subaddresses will have to be extended. There is some consensus that an AESA address with another AESA as subaddress needs to be allowed. In addition, more than two layers of addressing will be needed in some cases. These issues have not been thrashed out to the point where we know what will happen. > (Or are you just obliquely trying to point out to the original author > that there's an entirely different MIB element dedicated to > subaddresses? If that's the case, and I'm no MIB expert, just say it.) > > gja Mickey   Received: from cnri by ietf.org id aa21913; 28 Mar 97 19:23 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa23544; 28 Mar 97 19:23 EST Received: from VNET.IBM.COM (vnet.ibm.com [199.171.26.4]) by thumper.bellcore.com (8.8.5/8.8.5) with SMTP id TAA05851 for ; Fri, 28 Mar 1997 19:02:09 -0500 (EST) Message-Id: <199703290002.TAA05851@thumper.bellcore.com> Received: from RALVM12 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 2399; Fri, 28 Mar 97 19:02:07 EST Date: Fri, 28 Mar 97 18:57:03 EST From: kennethw@vnet.ibm.com To: mspiegel@cisco.com cc: ion@nexen.com, atommib@thumper.bellcore.com Subject: IPOA Textual Conventions Mickey, Several of the folks participating on the ion mailing list expressed an opinion that to infer the type of an address based on OCTET STRING length was not the best design, hence the creation of the IpoaAtmAddrKind. Internally, at least within my own area's implementation, a type field and a length field will exist. There was some discussion on the ion mailing list that E.164 addresses could be variable and not limited to either 9 octets (BCD) encoding or 15 octets (native) encoding. This seems to indicate that inferring a physical address type based on length to be flawed and that a type field was needed. There was also the opinion by some that their implementation did not want to have to convert a native encoded E.164 address to a BCD one in order to place a value in the MIB. In the IPOA MIB an ATM Physical address can be a combination of both address and subaddress. I do agree that these can be separated into two separate objects. This would cause the addition of a few new objects of which a few would have to be added to the INDEX clause of a couple of tables. Which approach is best can be debated. I am not overly found of OCTET STRING indexes to begin with. I had forgotten the SYNTAX clause in my posting: SYNTAX OCTET STRING (SIZE(0..20)) my MIB compiler had pointed this out to me before you did. Sorry I made the posting prior to compiling it. The order of address and subaddress for a structure 3 address was inferred (perhaps only in my mind) by the naming of the enumeration elements in IpoaAtmAddrKind. Ken   Received: from cnri by ietf.org id aa22494; 28 Mar 97 19:47 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa23879; 28 Mar 97 19:47 EST Received: from foxhound.cisco.com (foxhound.cisco.com [171.69.192.161]) by thumper.bellcore.com (8.8.5/8.8.5) with ESMTP id TAA06321 for ; Fri, 28 Mar 1997 19:24:04 -0500 (EST) Received: from cisco.com (localhost [127.0.0.1]) by foxhound.cisco.com (8.8.4-Cisco.1/8.6.5) with ESMTP id QAA04245; Fri, 28 Mar 1997 16:23:23 -0800 (PST) Message-Id: <199703290023.QAA04245@foxhound.cisco.com> To: kennethw@vnet.ibm.com cc: ion@nexen.com, atommib@thumper.bellcore.com Subject: Re: IPOA Textual Conventions In-reply-to: Your message of "Fri, 28 Mar 1997 18:57:03 EST." <199703290002.QAA18902@hubbub.cisco.com> Date: Fri, 28 Mar 1997 16:23:21 -0800 From: Mickey Spiegel Ken, Thanks for the reply. I still believe that there is nothing specific to IPOA in your proposed textual conventions. We could change the AtmAddr textual convention, but this might give rise to migration issues. > Several of the folks participating on the ion mailing list > expressed an opinion that to infer the type of an address based on > OCTET STRING length was not the best design, hence the creation of > the IpoaAtmAddrKind. Internally, at least within my own area's > implementation, a type field and a length field will exist. The current method may be a little ugly, but there are existing MIBs that rely on this method to determine the ATM address type. It might not hurt to add an AtmAddrKind TC which may or may not be used by any particular MIB. > There was some discussion on the ion mailing list that E.164 > addresses could be variable and not limited to either 9 octets > (BCD) encoding or 15 octets (native) encoding. This seems to > indicate that inferring a physical address type based on length > to be flawed and that a type field was needed. > There was also the opinion by some that their implementation > did not want to have to convert a native encoded E.164 address to > a BCD one in order to place a value in the MIB. I do not know why a BCD encoding was chosen, since signalling uses an encoding as IA5 characters. ILMI uses the BCD coding. Either way, both codings represent the same address and address type. Conversion may be ugly, but do we really want to have two different encodings and address types to represent the same thing? > In the IPOA MIB an ATM Physical address can be a combination of > both address and subaddress. I do agree that these can be separated > into two separate objects. This would cause the addition of a few > new objects of which a few would have to be added to the INDEX > clause of a couple of tables. Which approach is best can be debated. > I am not overly found of OCTET STRING indexes to begin with. > I had forgotten the SYNTAX clause in my posting: > > SYNTAX OCTET STRING (SIZE(0..20)) A native E.164 address plus an AESA adds up to 35 ... > my MIB compiler had pointed this out to me before you did. Sorry I > made the posting prior to compiling it. The order of address and > subaddress for a structure 3 address was inferred (perhaps only > in my mind) by the naming of the enumeration elements in IpoaAtmAddrKind. > > Ken Mickey   Received: from cnri by ietf.org id aa23133; 28 Mar 97 20:15 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa24303; 28 Mar 97 20:15 EST Received: from VNET.IBM.COM (vnet.ibm.com [199.171.26.4]) by thumper.bellcore.com (8.8.5/8.8.5) with SMTP id TAA06964 for ; Fri, 28 Mar 1997 19:55:30 -0500 (EST) Message-Id: <199703290055.TAA06964@thumper.bellcore.com> Received: from RALVM12 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 3032; Fri, 28 Mar 97 19:55:28 EST Date: Fri, 28 Mar 97 19:48:12 EST From: kennethw@vnet.ibm.com To: mspiegel@cisco.com cc: ion@nexen.com, atommib@thumper.bellcore.com Subject: Re: IPOA Textual Conventions Mickey, >I still believe that there is nothing specific to IPOA in your >proposed textual conventions. We could change the AtmAddr textual >convention, but this might give rise to migration issues. >> Several of the folks participating on the ion mailing list >> expressed an opinion that to infer the type of an address based on >> OCTET STRING length was not the best design, hence the creation of >> the IpoaAtmAddrKind. Internally, at least within my own area's >> implementation, a type field and a length field will exist. >The current method may be a little ugly, but there are existing MIBs >that rely on this method to determine the ATM address type. It might >not hurt to add an AtmAddrKind TC which may or may not be used by >any particular MIB. >> There was some discussion on the ion mailing list that E.164 >> addresses could be variable and not limited to either 9 octets >> (BCD) encoding or 15 octets (native) encoding. This seems to >> indicate that inferring a physical address type based on length >> to be flawed and that a type field was needed. >> There was also the opinion by some that their implementation >> did not want to have to convert a native encoded E.164 address to >> a BCD one in order to place a value in the MIB. >I do not know why a BCD encoding was chosen, since signalling uses an >encoding as IA5 characters. ILMI uses the BCD coding. Either way, >both codings represent the same address and address type. Conversion >may be ugly, but do we really want to have two different encodings >and address types to represent the same thing? The point of allowing a native encoding of a E.164 addresses was to allow an implementation to decide and not force the conversion. >> In the IPOA MIB an ATM Physical address can be a combination of >> both address and subaddress. I do agree that these can be separated >> into two separate objects. This would cause the addition of a few >> new objects of which a few would have to be added to the INDEX >> clause of a couple of tables. Which approach is best can be debated. >> I am not overly found of OCTET STRING indexes to begin with. >> I had forgotten the SYNTAX clause in my posting: >> >> SYNTAX OCTET STRING (SIZE(0..20)) >A native E.164 address plus an AESA adds up to 35 ... Right. >> my MIB compiler had pointed this out to me before you did. Sorry I >> made the posting prior to compiling it. The order of address and >> subaddress for a structure 3 address was inferred (perhaps only >> in my mind) by the naming of the enumeration elements in IpoaAtmAddrKind. I beleive that AtmAddr's SYNTAX is: SYNTAX OCTET STRING (SIZE(0 8 20)) could it be changed to: SYNTAX OCTET STRING (SIZE(0..20)) instead? It's DESCRIPTION clause could also be modified with out effecting current implementations. Then given the following: AtmAddrKind ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Defines the format of a ATM Physical Address, AtmAddr objects, as follows: none(1) No ATM Address specified. aesa(2) Structure 1, 20 octet ATM Forum ATM Address encoded as an NSAP form ATM EndSystem Address (AESA) bcdE164(3) Structure 2,(usually 9 octet) BCD encoded E.164 address. nativeE164(4) Structure 2, (usually 15 octet) native encoded E.164 address. An E.164 encoded address is usually 9 octets if BCD encoded and 15 octets if native encoded. The actually length of a E.164 address can be inferred from the number of octets for a AtmAddr object and a corresponding AtmAddrKind object." SYNTAX INTEGER { none(1), aesa(2), bcdE164(3), nativeE164(4) } I would then have to break up the address and subaddress into 2 separate objects. Ken   Received: from cnri by ietf.org id aa24036; 28 Mar 97 20:48 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa24744; 28 Mar 97 20:48 EST Received: from foxhound.cisco.com (foxhound.cisco.com [171.69.192.161]) by thumper.bellcore.com (8.8.5/8.8.5) with ESMTP id UAA07455 for ; Fri, 28 Mar 1997 20:24:35 -0500 (EST) Received: from cisco.com (localhost [127.0.0.1]) by foxhound.cisco.com (8.8.4-Cisco.1/8.6.5) with ESMTP id RAA05331; Fri, 28 Mar 1997 17:23:56 -0800 (PST) Message-Id: <199703290123.RAA05331@foxhound.cisco.com> To: kennethw@vnet.ibm.com cc: ion@nexen.com, atommib@thumper.bellcore.com Subject: Re: IPOA Textual Conventions In-reply-to: Your message of "Fri, 28 Mar 1997 19:48:12 EST." <199703290055.QAA23195@hubbub.cisco.com> Date: Fri, 28 Mar 1997 17:23:56 -0800 From: Mickey Spiegel > >I still believe that there is nothing specific to IPOA in your > >proposed textual conventions. We could change the AtmAddr textual > >convention, but this might give rise to migration issues. > > >> Several of the folks participating on the ion mailing list > >> expressed an opinion that to infer the type of an address based on > >> OCTET STRING length was not the best design, hence the creation of > >> the IpoaAtmAddrKind. Internally, at least within my own area's > >> implementation, a type field and a length field will exist. > > >The current method may be a little ugly, but there are existing MIBs > >that rely on this method to determine the ATM address type. It might > >not hurt to add an AtmAddrKind TC which may or may not be used by > >any particular MIB. > > >> There was some discussion on the ion mailing list that E.164 > >> addresses could be variable and not limited to either 9 octets > >> (BCD) encoding or 15 octets (native) encoding. This seems to > >> indicate that inferring a physical address type based on length > >> to be flawed and that a type field was needed. Use the coding rules in Section 5.1.3.1.1.3 of UNI 3.1 to encode a variable length native E.164 address in a BCD format of length 8 bytes. Using this format, the original variable length native E.164 address can be rederived. > >> There was also the opinion by some that their implementation > >> did not want to have to convert a native encoded E.164 address to > >> a BCD one in order to place a value in the MIB. > > >I do not know why a BCD encoding was chosen, since signalling uses an > >encoding as IA5 characters. ILMI uses the BCD coding. Either way, > >both codings represent the same address and address type. Conversion > >may be ugly, but do we really want to have two different encodings > >and address types to represent the same thing? > > The point of allowing a native encoding of a E.164 addresses was to > allow an implementation to decide and not force the conversion. ILMI and numerous existing MIBs already force the conversion. I still think it is uglier to have two formats for the same thing than to do the conversion. > >> In the IPOA MIB an ATM Physical address can be a combination of > >> both address and subaddress. I do agree that these can be separated > >> into two separate objects. This would cause the addition of a few > >> new objects of which a few would have to be added to the INDEX > >> clause of a couple of tables. Which approach is best can be debated. > >> I am not overly found of OCTET STRING indexes to begin with. > >> I had forgotten the SYNTAX clause in my posting: > >> > >> SYNTAX OCTET STRING (SIZE(0..20)) > > >A native E.164 address plus an AESA adds up to 35 ... > > Right. > > >> my MIB compiler had pointed this out to me before you did. Sorry I > >> made the posting prior to compiling it. The order of address and > >> subaddress for a structure 3 address was inferred (perhaps only > >> in my mind) by the naming of the enumeration elements in IpoaAtmAddrKind. > > I beleive that AtmAddr's SYNTAX is: > > SYNTAX OCTET STRING (SIZE(0 8 20)) > > could it be changed to: > > SYNTAX OCTET STRING (SIZE(0..20)) > > instead? This is where the migration issues come in. ILMI uses the fixed length 8 byte BCD encoding for E.164 addresses. Numerous other existing MIBs also use the 8 byte encoding. There are many TCs called AtmAddr using the (0|8|20) syntax. Given that the current TC is not broken and is in widespread use, why change it? Perhaps the choices the first time around were not perfect, but I would rather have one way of coding ATM addresses than multiple ... > It's DESCRIPTION clause could also be modified with out > effecting current implementations. Then given the following: > > AtmAddrKind ::= TEXTUAL-CONVENTION > STATUS current > DESCRIPTION > "Defines the format of a ATM Physical Address, > AtmAddr objects, as follows: > > none(1) No ATM Address specified. > aesa(2) Structure 1, 20 octet ATM Forum > ATM Address encoded as an NSAP form > ATM EndSystem Address (AESA) > bcdE164(3) Structure 2,(usually 9 octet) BCD encoded > E.164 address. > nativeE164(4) Structure 2, (usually 15 octet) native > encoded E.164 address. > > An E.164 encoded address is usually 9 octets if BCD encoded > and 15 octets if native encoded. The actually length of a > E.164 address can be inferred from the number of octets > for a AtmAddr object and a corresponding AtmAddrKind object." > SYNTAX INTEGER { > none(1), > aesa(2), > bcdE164(3), > nativeE164(4) > } > > I would then have to break up the address and subaddress into 2 > separate objects. > > Ken Mickey   Received: from cnri by ietf.org id aa24107; 28 Mar 97 20:49 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa24773; 28 Mar 97 20:49 EST Received: from foxhound.cisco.com (foxhound.cisco.com [171.69.192.161]) by thumper.bellcore.com (8.8.5/8.8.5) with ESMTP id UAA07502 for ; Fri, 28 Mar 1997 20:28:16 -0500 (EST) Received: (kzm@localhost) by foxhound.cisco.com (8.8.4-Cisco.1/8.6.5) id RAA05441; Fri, 28 Mar 1997 17:27:38 -0800 (PST) From: Keith McCloghrie Message-Id: <199703290127.RAA05441@foxhound.cisco.com> Subject: Re: IPOA Textual Conventions To: kennethw@vnet.ibm.com Date: Fri, 28 Mar 1997 17:27:38 -0800 (PST) Cc: mspiegel@cisco.com, ion@nexen.com, atommib@thumper.bellcore.com In-Reply-To: <199703290002.TAA05851@thumper.bellcore.com> from "kennethw@vnet.ibm.com" at Mar 28, 97 06:57:03 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit I suggest it's 4 years too late to be changing this. The use of different lengths to represent address types has been a part of ATM standards since the UNI 3.0 spec. (In fact, all ATM Forum member companies have already approved this three times :-) The current method works - if it ain't broke, don't fix it. > Several of the folks participating on the ion mailing list > expressed an opinion that to infer the type of an address based on > OCTET STRING length was not the best design, hence the creation of > the IpoaAtmAddrKind. Internally, at least within my own area's > implementation, a type field and a length field will exist. Having separate MIB objects for type and length is more complicated. Do we want to make ATM more complicated ? > There was some discussion on the ion mailing list that E.164 > addresses could be variable and not limited to either 9 octets > (BCD) encoding or 15 octets (native) encoding. This seems to > indicate that inferring a physical address type based on length > to be flawed and that a type field was needed. Read the E.164 section in any of the UNI 3.0, 3.1 and 4.0 specifications, and you'll find that it's the above statement that's broken, not the current AToM MIB or ILMI objects. > There was also the opinion by some that their implementation > did not want to have to convert a native encoded E.164 address to > a BCD one in order to place a value in the MIB. It's a couple of lines of infrequently-executed code. Compared to the size/complexities of signaling code, this is trivial. Keith.   Received: from cnri by ietf.org id aa27448; 28 Mar 97 22:58 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa26701; 28 Mar 97 22:58 EST Received: from VNET.IBM.COM (vnet.ibm.com [199.171.26.4]) by thumper.bellcore.com (8.8.5/8.8.5) with SMTP id WAA09688 for ; Fri, 28 Mar 1997 22:34:55 -0500 (EST) Message-Id: <199703290334.WAA09688@thumper.bellcore.com> Received: from RALVM12 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 4340; Fri, 28 Mar 97 22:34:53 EST Date: Fri, 28 Mar 97 22:29:36 EST From: kennethw@vnet.ibm.com To: kzm@cisco.com cc: mspiegel@cisco.com, ion@nexen.com, atommib@thumper.bellcore.com Keith, >I suggest it's 4 years too late to be changing this. The use of >different lengths to represent address types has been a part of ATM >standards since the UNI 3.0 spec. (In fact, all ATM Forum member >companies have already approved this three times :-) >The current method works - if it ain't broke, don't fix it. >> Several of the folks participating on the ion mailing list >> expressed an opinion that to infer the type of an address based on >> OCTET STRING length was not the best design, hence the creation of >> the IpoaAtmAddrKind. Internally, at least within my own area's >> implementation, a type field and a length field will exist. >Having separate MIB objects for type and length is more complicated. >Do we want to make ATM more complicated ? RFC1695 and the Definitions of Managed Objects for ATM Management, January 8, 1997 Internet Draft both define an ATM Address type: atmInterfaceAddressType OBJECT-TYPE SYNTAX INTEGER { private(1), nsapE164(2), nativeE164(3), other(4) } MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The type of primary ATM address configured for use at this ATM interface." ::= { atmInterfaceConfEntry 9 } I realize that the above object is deprecated in the new draft but is still current in RFC1695. According to RFC1903 deprecated means: '"deprecated" value indicates that the definition is obsolete, but that an implementor may wish to support the use of this textual convention to foster interoperability with older implementations.' I never suggested that a length field be defined. I have been discussing definitions for defining ATM Addresses subaddresses and an address type. Given the current definition of AtmAddr how can a atmInterfaceAdminAddr object have a valid value when its SYNTAX is 0, 8 or 20 octets when it's address type is nativeE164? >> There was some discussion on the ion mailing list that E.164 >> addresses could be variable and not limited to either 9 octets >> (BCD) encoding or 15 octets (native) encoding. This seems to >> indicate that inferring a physical address type based on length >> to be flawed and that a type field was needed. >Read the E.164 section in any of the UNI 3.0, 3.1 and 4.0 specifications, >and you'll find that it's the above statement that's broken, not the >current AToM MIB or ILMI objects. I agree that variable length E.164 addresses from a MIB perspective don't really exists since it would be padded with leading zeros to the expected length. >> There was also the opinion by some that their implementation >> did not want to have to convert a native encoded E.164 address to >> a BCD one in order to place a value in the MIB. >It's a couple of lines of infrequently-executed code. Compared to >the size/complexities of signaling code, this is trivial. Granted that in the new ATM MIB an address type field doesn't exist. It does to some extent in RFC1695. I am not all that adamant about adding an address field but want to explore the issues. In the AToMMIB working group how are structure 3 addresses represented? Classic2 has a requirement for this. At one time I remember being told that it was out of scope but its been a while and I may be wrong as to what I remember. Given that the IPOA MIB has both an ATM Address and a subaddress how would you recommend modeling them? As a single or as separate objects? The IPOA MIB using the ATM Address and subaddress as an index into at least two tables. If I separate them out and include both as indexes then for non-structure 3 addresses the subaddress would be a null octet string. I would also have a problem in setting ifPhysAddress. Ken   Received: from cnri by ietf.org id aa05976; 30 Mar 97 2:00 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa02796; 30 Mar 97 2:00 EST Received: from one-o.com (canaan.one-o.com [206.151.128.11]) by thumper.bellcore.com (8.8.5/8.8.5) with SMTP id BAA28414 for ; Sun, 30 Mar 1997 01:27:27 -0500 (EST) Received: from jericho.one-o.com (jericho [206.151.128.12]) by one-o.com (SMI-8.6/SMI-SVR4-OOI951120) id WAA05219; Sat, 29 Mar 1997 22:27:24 -0800 Received: (from heard@localhost) by jericho.one-o.com (SMI-8.6/SMI-SVR4) id WAA18343; Sat, 29 Mar 1997 22:27:23 -0800 Date: Sat, 29 Mar 1997 22:27:23 -0800 Message-Id: <199703300627.WAA18343@jericho.one-o.com> To: atommib@thumper.bellcore.com Subject: Re: SONET/SDH Suppl MIB From: "C. M. Heard/VVNET, Inc." Mime-Version: 1.0 On Mon, 17 Mar 1997 Kaj Tesink wrote: > > i have still an action item to clone the suppl ds1/ds3 mibs > for sonet/sdh. since these suppl mibs seem to differ somewhat > i want to make sure i have the functional requirements right. > > what about this list: > > suppl sonet/sdh mib functions: > - thresholding > - day interval counters > - reset capability After reviewing both the trunkmib WG minutes and Maria Greene's excellent memo I am happy to endorse this list. Is is a well-focussed list, and it is 100% consistent with Maria's memo except for the absence of invalid data flags, which are now in the main sonet mib (consistent with the decision documented in the trunkmib minutes for the other trunk mibs). Having said that, allow me to point out -- just so that we proceed with our eyes open -- that this list does _not_ include all of the required items from ANSI T1.231-1993 and the draft revision T1M1.3/97-011R3 which the sonet mib omits. Specifically, failure counts are required by both the 1993 version and the proposed revision of T1.231, and are not present in the main sonet mib (although failures _are_ defined in the narrative part of the document), and the draft revision of T1.231 now requires SONET NEs to maintain statistics on pointer justification events. I don't think that pointer justification statistics are worth including in the sonet supplemental mib. They are an issue for multiplexing equipment (like a SONET ADM) which removes a synchronous payload from one SPE and puts it in another, but not for equipment which terminates a SONET trunk, such as an ATM switch or host. I imagine that most of the applications of the sonet mib are to equipment of the latter variety -- SONET ADMs tend to use OSI protocol stacks, not SNMP, don't they? On the issue of failure counts I am more ambivalent -- although I'm not eager to implement failure detection and clearing logic in my instrumentation, I would probably do so if failure count objects were in the mib. On the other hand, I would be most unhappy to see the sonet supplemental mib get overgrown like the draft DS3 supplemental mib , which in my opinion has far too broad a scope. So I will not press to include FC objects in the mib but rather I accept Kaj's well-focussed list as it stands. Mike -- C. M. Heard VVNET, Inc. phone: +1 408 247 9376 4040 Moorpark Ave. Suite 206 fax: +1 408 244 3651 San Jose, CA 95117 USA e-mail: heard@vvnet.com   Received: from cnri by ietf.org id aa06988; 30 Mar 97 3:46 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa04348; 30 Mar 97 3:45 EST Received: from one-o.com (canaan.one-o.com [206.151.128.11]) by thumper.bellcore.com (8.8.5/8.8.5) with SMTP id DAA29476 for ; Sun, 30 Mar 1997 03:18:17 -0500 (EST) Received: from jericho.one-o.com (jericho [206.151.128.12]) by one-o.com (SMI-8.6/SMI-SVR4-OOI951120) id AAA06526; Sun, 30 Mar 1997 00:18:12 -0800 Received: (from heard@localhost) by jericho.one-o.com (SMI-8.6/SMI-SVR4) id AAA18609; Sun, 30 Mar 1997 00:18:11 -0800 Date: Sun, 30 Mar 1997 00:18:11 -0800 From: "Charles M. Heard" Message-Id: <199703300818.AAA18609@jericho.one-o.com> To: atommib@thumper.bellcore.com Subject: Re: agenda ietf In-Reply-To: <3.0.16.19970328155639.2a3fbd00@joker.bellcore.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="aa00000000" Content-Transfer-Encoding: 7bit --aa00000000 Content-Type: text/plain; charset=us-ascii On Fri Mar 28 1997 Kaj Tesink wrote: > > you may have noticed that the atommib wg will have only one > meeting slot at the next ietf. [ ... ] in this one slot we > need to cover the following: > > 1 wrapup suppl atm mib > > 2 test mib and atm test mib > > 3 mib for ATM Performance History Data Based on 15 Minute Intervals > > 4 any requirements for a supplemental sonet/sdh mib a la > the other supplemental trunk mibs > > a full plate indeed. my assumption is that most time will be spend > on items 1 and 4. please come prepared! Unfortunately I can't come at all :-( so I must make do with submitting my comments to the mailing list. I have already endorsed Kaj's proposed requirements for item 4 (assuming that the sonet supplemental mib will be based on and _not_ on ). At the last IETF meeting I submitted some comments regarding the ATM Performance History Data Based on 15 Minute Intervals (item 3 -- ), but there has been no further discussion on the mailing list. I have attached my comments in case this mib is actually discussed in Memphis. I _do_ note that many of the objects in seem to be redundant with objects in the recently proposed ATM Forum ATM-FORUM-M4-MIB (ATM_Forum/97-0047, A. Malis, February 1997). It seems to me if the ATM Forum intends to move forward with 97-0047 it would probably be best _not_ to publish an SNMP mib with overlapping functionality in the IETF. Best wishes for a productive session, Mike -- C. M. Heard VVNET, Inc. phone: +1 408 247 9376 4040 Moorpark Ave. Suite 206 fax: +1 408 244 3651 San Jose, CA 95117 USA e-mail: heard@vvnet.com --aa00000000 Content-Type: text/plain; charset=us-ascii Content-Description: comments on My comments concern the per-interface ATM Cell Layer Current Data table (atmProtoCurrTable) and the per-interface and time interval ATM Cell Layer History Data (atmProtoHistTable) and the MIB conformance groups. Specifically, I think that: 1.) The object atmProtoCurrClp0CellIns should be removed from the atmProtoCurrTable and the object atmProtoHistClp0CellIns should be removed from the atmProtoHistTable, and the descriptions for the objects atmProtoCurrTotalCellIns and atmProtoHistTotalCellIns should be corrected; 2.) new objects atmProtoCurrTotalCellOuts and atmProtoCurrOutErrors should be added to atmProtoCurrTable and new objects atmProtoHistTotalCellOuts and atmProtoHistOutErrors should be added to atmProtoHistTable; and 3.) there should be three conformance groups: atmHistIfGroup, which contains all the per-interface objects and is mandatory for all systems; atmHistVplGroup, which contains all the per-VPL objects and is mandatory for systems which terminate VPLs; and atmHistVclGroup, which contains all the per-VCL objects and is mandatory for systems which terminate VCls. Rationale: 1.) The descriptions for atmProtoCurrTotalCellIns, atmProtoCurrClp0CellIns, atmProtoHistTotalCellIns, and atmProtoHistClp0CellIns parallel those for similar per-VPL objects which are used to record UPC/NPC-related statistics, and make reference to traffic policing functions. Traffic policing, however, is _never_ done on a per-interface basis; it is _always_ done on a per-VPL or per-VCL basis, and it varies from one VPL or VCL to another. Indeed, in some CBR traffic contracts the CLP bit does not indicate a discard priority but is transported transparently from end-to-end. For this reason I think that per-interface (as opposed to per-VPL or per-VCL) counts of CLP0 cells are not useful, and the atmProtoCurrClp0CellIns and atmProtoHistClp0CellIns objects should be removed. In addition, the descriptions of atmProtoCurrTotalCellIns and atmProtoHistTotalCellIns should make no reference to traffic policing (or "this VPL") and should be aligned with the descriptions of ifInOctets and ifHCInOctets in section 7.2.1. of ("Support of the ATM Cell Layer by ifTable"), since ifInOctets and ifHCInOctets are (apart from a factor of 53) cumulative versions of atmProtoCurrTotalCellIns and atmProtoHistTotalCellIns. [Note how the descriptions of atmProtoCurrProtoErrors/atmHistCurrProtoErrors and atmProtoCurrDiscardHECViol/atmProtoHistDiscardHECViol already agree with those of ifInUnknownProtos and ifInErrors, respectively.] 2.) atmProtoCurrTotalCellOuts/atmProtoHistTotalCellOuts and atmProtoCurrOutErrors/atmProtoHistOutErrors are proposed as interval-based versions of the cumulative ifTable counters ifOutOctets/IfHCOutOctets and IfOutErrors, respectively. History objects are just as useful for transmit-side statistics and they are for receive-side statistics; to omit while including the other seems needless and arbitrary, _particularly_ since the omission was done only for the per-interface objects (and not the per-VPL and per-VPL objects). 3.) I propose separate groups atmHistIfGroup, atmHistVplGroup, and atmHistVclGroup so that conforming systems may implement just the applicable MIB objects. Switches and end systems would always implement atmHistIfGroup and one or both of atmHistVplGroup and atmHistVclGroup; test equipment which just monitors a trunk (my application :-) would implement just the per-interface atmHistIfGroup. A context diff follows showing the exact changes I propose. Line numbers and page breaks are aligned with . The revised mib has been stripped and compiles OK with mosy (I have not been able to run it thru smicng). /cmh *** draft-ietf-atommib-atmhist-00.txt Mon Nov 25 22:00:03 1996 --- draft-ietf-atommib-atmhist-00.txt Sat Mar 29 19:52:12 1997 *************** *** 179,187 **** atmProtoCurrSuspect TruthValue, atmProtoCurrTimeElapsed INTEGER, atmProtoCurrTotalCellIns PerfCurrentCount, - atmProtoCurrClp0CellIns PerfCurrentCount, atmProtoCurrProtoErrors PerfCurrentCount, ! atmProtoCurrDiscardHECViol PerfCurrentCount } atmProtoCurrSuspect OBJECT-TYPE --- 179,188 ---- atmProtoCurrSuspect TruthValue, atmProtoCurrTimeElapsed INTEGER, atmProtoCurrTotalCellIns PerfCurrentCount, atmProtoCurrProtoErrors PerfCurrentCount, ! atmProtoCurrDiscardHECViol PerfCurrentCount, ! atmProtoCurrTotalCellOuts PerfCurrentCount, ! atmProtoCurrOutErrors PerfCurrentCount } atmProtoCurrSuspect OBJECT-TYPE *************** *** 206,221 **** MAX-ACCESS read-only STATUS current DESCRIPTION ! "The total number of valid ATM cells received by this VCL ! including both CLP=0 and CLP=1 cells. The cells are ! counted prior to the application of the traffic policing." ::= { atmProtoCurrEntry 3 } - atmProtoCurrClp0CellIns OBJECT-TYPE - SYNTAX PerfCurrentCount - MAX-ACCESS read-only - - Expires April 1997 [Page 4] --- 207,217 ---- MAX-ACCESS read-only STATUS current DESCRIPTION ! "The total number of assigned, valid ATM cells received ! on this interface since the start of the current interval." ::= { atmProtoCurrEntry 3 } + Expires April 1997 [Page 4] *************** *** 222,234 **** Internet-Draft ATM Performance History MIB November 1996 - STATUS current - DESCRIPTION - "The number of valid ATM cells received by this VCL - with CLP=0. The cells are counted prior to the - application of the traffic policing." - ::= { atmProtoCurrEntry 4 } - atmProtoCurrProtoErrors OBJECT-TYPE SYNTAX PerfCurrentCount MAX-ACCESS read-only --- 218,223 ---- *************** *** 237,243 **** "The number of ATM cells dropped on this interface, due to an unrecognized field or set of fields in the ATM cell header, since the start of this interval." ! ::= { atmProtoCurrEntry 5 } atmProtoCurrDiscardHECViol OBJECT-TYPE SYNTAX PerfCurrentCount --- 226,232 ---- "The number of ATM cells dropped on this interface, due to an unrecognized field or set of fields in the ATM cell header, since the start of this interval." ! ::= { atmProtoCurrEntry 4 } atmProtoCurrDiscardHECViol OBJECT-TYPE SYNTAX PerfCurrentCount *************** *** 246,257 **** DESCRIPTION "The number of ATM cells discarded on this interface, due to an HEC violation, since the start of this interval." ::= { atmProtoCurrEntry 6 } -- ATM Cell Protocol Monitoring History Data (per interface and time ! interval) atmProtoHistTable OBJECT-TYPE SYNTAX SEQUENCE OF AtmProtoHistEntry --- 235,263 ---- DESCRIPTION "The number of ATM cells discarded on this interface, due to an HEC violation, since the start of this interval." + ::= { atmProtoCurrEntry 5 } + + atmProtoCurrTotalCellOuts OBJECT-TYPE + SYNTAX PerfCurrentCount + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The total number of assigned, valid ATM cells transmitted + on this interface since the start of the current interval." ::= { atmProtoCurrEntry 6 } + atmProtoCurrOutErrors OBJECT-TYPE + SYNTAX PerfCurrentCount + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of ATM cells which could not be transmitted on + this interface because of errors." + ::= { atmProtoCurrEntry 7 } -- ATM Cell Protocol Monitoring History Data (per interface and time ! -- interval) atmProtoHistTable OBJECT-TYPE SYNTAX SEQUENCE OF AtmProtoHistEntry *************** *** 289,297 **** atmProtoHistEndTime TimeStamp, atmProtoHistSuspect TruthValue, atmProtoHistTotalCellIns PerfIntervalCount, - atmProtoHistClp0CellIns PerfIntervalCount, atmProtoHistProtoErrors PerfIntervalCount, ! atmProtoHistDiscardHECViol PerfIntervalCount } atmProtoHistIndex OBJECT-TYPE --- 295,304 ---- atmProtoHistEndTime TimeStamp, atmProtoHistSuspect TruthValue, atmProtoHistTotalCellIns PerfIntervalCount, atmProtoHistProtoErrors PerfIntervalCount, ! atmProtoHistDiscardHECViol PerfIntervalCount, ! atmProtoHistTotalCellOuts PerfIntervalCount, ! atmProtoHistOutErrors PerfIntervalCount } atmProtoHistIndex OBJECT-TYPE *************** *** 335,355 **** DESCRIPTION ! "The total number of valid ATM cells received by this VCL ! including both CLP=0 and CLP=1 cells. The cells are ! counted prior to the application of the traffic policing." ::= { atmProtoHistEntry 4 } - atmProtoHistClp0CellIns OBJECT-TYPE - SYNTAX PerfIntervalCount - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The number of valid ATM cells received by this VCL - with CLP=0. The cells are counted prior to the - application of the traffic policing." - ::= { atmProtoHistEntry 5 } - atmProtoHistProtoErrors OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only --- 342,351 ---- DESCRIPTION ! "The total number of assigned, valid ATM cells received ! on this interface since the start of the current interval." ::= { atmProtoHistEntry 4 } atmProtoHistProtoErrors OBJECT-TYPE SYNTAX PerfIntervalCount MAX-ACCESS read-only *************** *** 358,364 **** "The number of ATM cells dropped on this interface, due to an unrecognized field or set of fields in the ATM cell header, since the start of this interval." ! ::= { atmProtoHistEntry 6 } atmProtoHistDiscardHECViol OBJECT-TYPE SYNTAX PerfIntervalCount --- 354,360 ---- "The number of ATM cells dropped on this interface, due to an unrecognized field or set of fields in the ATM cell header, since the start of this interval." ! ::= { atmProtoHistEntry 5 } atmProtoHistDiscardHECViol OBJECT-TYPE SYNTAX PerfIntervalCount *************** *** 367,375 **** --- 363,389 ---- DESCRIPTION "The number of ATM cells discarded on this interface, due to an HEC violation, since the start of this interval." + ::= { atmProtoHistEntry 6 } + + atmProtoHistTotalCellOuts OBJECT-TYPE + SYNTAX PerfIntervalCount + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The total number of assigned, valid ATM cells transmitted + on this interface since the start of the current interval." ::= { atmProtoHistEntry 7 } + atmProtoHistOutErrors OBJECT-TYPE + SYNTAX PerfIntervalCount + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of ATM cells which could not be transmitted on + this interface because of errors." + ::= { atmProtoHistEntry 8 } + -- UPC/NPC Monitoring Current Data (per VPL termination point) -- These data are only recorded for permanent connections. *************** *** 997,1003 **** "The compliance statement for SNMP entities that support ATM History Data." MODULE -- this module ! MANDATORY-GROUPS { atmHistGroup } ::= { atmHistMIBCompliances 1 } --- 1011,1025 ---- "The compliance statement for SNMP entities that support ATM History Data." MODULE -- this module ! MANDATORY-GROUPS { atmHistIfGroup } ! GROUP atmHistVplGroup ! DESCRIPTION ! "Implementation of this group is mandatory for ! systems that terminate Virtual Path Links." ! GROUP atmHistVclGroup ! DESCRIPTION ! "Implementation of this group is mandatory for ! systems that terminate Virtual Channel Links." ::= { atmHistMIBCompliances 1 } *************** *** 1009,1028 **** -- Units of Conformance ! atmHistGroup OBJECT-GROUP OBJECTS { atmProtoCurrSuspect, atmProtoCurrTimeElapsed, atmProtoCurrTotalCellIns, - atmProtoCurrClp0CellIns, atmProtoCurrProtoErrors, atmProtoCurrDiscardHECViol, atmProtoHistEndTime , atmProtoHistSuspect, atmProtoHistTotalCellIns, - atmProtoHistClp0CellIns, atmProtoHistProtoErrors, atmProtoHistDiscardHECViol, atmVplCurrSuspect, atmVplCurrTimeElapsed, atmVplCurrTotalCellIns, --- 1031,1060 ---- -- Units of Conformance ! atmHistIfGroup OBJECT-GROUP OBJECTS { atmProtoCurrSuspect, atmProtoCurrTimeElapsed, atmProtoCurrTotalCellIns, atmProtoCurrProtoErrors, atmProtoCurrDiscardHECViol, + atmProtoCurrTotalCellOuts, + atmProtoCurrOutErrors, atmProtoHistEndTime , atmProtoHistSuspect, atmProtoHistTotalCellIns, atmProtoHistProtoErrors, atmProtoHistDiscardHECViol, + atmProtoHistTotalCellOuts, + atmProtoHistOutErrors + } + STATUS current + DESCRIPTION + "" + ::= { atmHistMIBGroups 1 } + + atmHistVplGroup OBJECT-GROUP + OBJECTS { atmVplCurrSuspect, atmVplCurrTimeElapsed, atmVplCurrTotalCellIns, *************** *** 1040,1046 **** atmVplHistDiscardedClp0, atmVplHistTotalCellOuts, atmVplHistClp0CellOuts, ! atmVplHistTaggedOuts, atmVclCurrSuspect, atmVclCurrTimeElapsed, atmVclCurrTotalCellIns, --- 1072,1086 ---- atmVplHistDiscardedClp0, atmVplHistTotalCellOuts, atmVplHistClp0CellOuts, ! atmVplHistTaggedOuts ! } ! STATUS current ! DESCRIPTION ! "" ! ::= { atmHistMIBGroups 2 } ! ! atmHistVclGroup OBJECT-GROUP ! OBJECTS { atmVclCurrSuspect, atmVclCurrTimeElapsed, atmVclCurrTotalCellIns, *************** *** 1071,1077 **** STATUS current DESCRIPTION "" ! ::= { atmHistMIBGroups 1 } END --- 1111,1117 ---- STATUS current DESCRIPTION "" ! ::= { atmHistMIBGroups 3 } END --aa00000000--   Received: from cnri by ietf.org id aa29322; 31 Mar 97 21:17 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa24727; 31 Mar 97 21:17 EST Received: from janus.3com.com (janus.3com.com [129.213.128.99]) by thumper.bellcore.com (8.8.5/8.8.5) with ESMTP id UAA13162 for ; Mon, 31 Mar 1997 20:52:07 -0500 (EST) Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by janus.3com.com (8.8.2/8.8.2) with ESMTP id RAA15953; Mon, 31 Mar 1997 17:51:35 -0800 (PST) Received: from chicago.nsd.3com.com (chicago.nsd.3com.com [129.213.157.11]) by new-york.3com.com (8.8.2/8.8.2) with ESMTP id RAA05526; Mon, 31 Mar 1997 17:49:56 -0800 (PST) Received: from bridge2.NSD.3Com.COM (bridge2.NSD.3Com.COM [129.213.96.3]) by chicago.nsd.3com.com (8.8.2/8.8.2) with ESMTP id RAA19022; Mon, 31 Mar 1997 17:50:34 -0800 (PST) Received: from sutter.NSD.3Com.COM (sutter.NSD.3Com.COM [129.213.48.47]) by bridge2.NSD.3Com.COM (8.8.2/8.8.2) with SMTP id RAA16547; Mon, 31 Mar 1997 17:51:33 -0800 (PST) Received: by sutter.NSD.3Com.COM id AA11983 (5.65c/IDA-1.4.4-910730); Mon, 31 Mar 1997 17:51:38 -0800 Date: Mon, 31 Mar 1997 17:51:38 -0800 From: Faye Ly Message-Id: <199704010151.AA11983@sutter.NSD.3Com.COM> To: atommib@thumper.bellcore.com, simon@switch.ch Subject: Re: Access to actual shaping/policing parameters? Simon, Thanks for bringing this up. For Switched VCs, these are the actual policing/shaping parameters. For the permanent VCs, however, these are used for configued as well as actual parameters. Anyone else has an oponion on this? Thanks. -faye fayely@3com.com   Received: from cnri by ietf.org id aa29755; 31 Mar 97 21:58 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa25273; 31 Mar 97 21:58 EST Received: from mailhost1.BayNetworks.COM (ns3.BayNetworks.COM [134.177.3.16]) by thumper.bellcore.com (8.8.5/8.8.5) with ESMTP id VAA14086 for ; Mon, 31 Mar 1997 21:33:39 -0500 (EST) Received: from ns1.BayNetworks.COM ([134.177.1.107]) by mailhost1.BayNetworks.COM (8.8.5/BNET-97/03/26-E) with ESMTP id SAA08484 Received: from pobox.corpwest.BayNetworks.COM (mailhost.corpwest.baynetworks.com [134.177.1.95]) by ns1.BayNetworks.COM (8.8.5/BNET-97/03/12-I) with ESMTP id SAA27242 Posted-Date: Mon, 31 Mar 1997 18:33:04 -0800 (PST) Received: from sc-mail2.corpwest.BayNetworks.com (sc-mail2-hme0.corpwest.baynetworks.com [134.177.64.102]) by pobox.corpwest.BayNetworks.COM (SMI-8.6/BNET-SVR4-S) with SMTP id SAA21435; Mon, 31 Mar 1997 18:33:03 -0800 for Received: from arao-pc2 (arao-pc2.engwest.baynetworks.com [134.177.120.226]) by sc-mail2.corpwest.BayNetworks.com (post.office MTA v2.0 0529 ID# 0-13459) with SMTP id AAA8671; Mon, 31 Mar 1997 18:33:00 -0800 Message-Id: <3.0.32.19970331183651.009aa490@sc-mail2.corpwest.baynetworks.com> X-Sender: arao@sc-mail2.corpwest.baynetworks.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 31 Mar 1997 18:36:52 -0800 To: Faye Ly , atommib@thumper.bellcore.com From: Anil Rao Subject: Re: atmVclAddrTable: should switch support this? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Hi, It is fine that we can implement a scheme wherein we have an On/Off action for this. By implementing this we say that we will reduce memory usage when we are not tracking Called Party/Calling Party address. We must further minimize the usage. Can we implement some scheme wherein we have a prefix for each switch and individual identifiers so that we can derive the address of the ATM entity ? Thanks, anil. At 11:48 PM 3/26/97 -0800, Faye Ly wrote: >Hi, > >During last IETF session, we discussed the pros and cons for implementing >atmVclAddrTable on ATM switch/service. I haven't seen any more >discussion on the mailing list regarding this issue. Here is a >summary and please comment: > >Support atmVclAddrTable for switch/service and provide an object >to turn it on/off. The default action should be off since it >is quite expensive for the ATM switch to save all the calling/ >called party addresses. The purpose for the ATM switch/service >to provide this table to the NMS is for the VC tracing. > >Thanks. > >-faye >fayely@3com.com >(408)764-6576 > ----------------------------------------------------------------- Anil R. Rao Phone: (408)495-1432 ATM Network Management Fax: (408)495-1498 Bay Networks, Inc. Internet: http://www.baynetworks.com MailStop SC1-05 Intranet: http://bayweb 4401 Great America Parkway Santa Clara, CA 95052 -----------------------------------------------------------------