and again .....
Tracy Cox <tacox@sabre.bellcore.com> Thu, 20 February 1992 14:39 UTC
Received: from nri.reston.va.us by NRI.NRI.Reston.VA.US id aa22319; 20 Feb 92 9:39 EST
Received: from FENNEL.ACC.COM by NRI.NRI.Reston.VA.US id aa22311; 20 Feb 92 9:39 EST
Received: from sabre.bellcore.com by fennel.acc.com (4.1/SMI-4.1) id AA12113; Thu, 20 Feb 92 06:34:27 PST
Received: by sabre.bellcore.com (5.57/Ultrix2.4-C) id AA08829; Thu, 20 Feb 92 09:34:55 EST
Return-Path: <tacox@sabre.bellcore.com>
Received: by ginsu4 (4.1/4.7) id AA00520; Thu, 20 Feb 92 09:33:26 EST
Date: Thu, 20 Feb 1992 09:33:26 -0500
From: Tracy Cox <tacox@sabre.bellcore.com>
X-Station-Sent-From: ginsu4.bellcore.com
Message-Id: <9202201433.AA00520@ginsu4>
To: trunk-mib@acc.com
Subject: and again .....
Status: O
Subject: reply on comments, long message Ed, In reply to your message below: ===================================================================== Date: Sun, 02 Feb 92 00:47:49 -0500 From: Ed Pring <pring@watson.ibm.com> OK, now I think I understand the situation you're trying to address, and why the current ds3 MIB definitions are a problem. To make sure, let me define some vocabulary and then give an example. Its confusing to me to use the word "interface" for both host system communications connections (the things listed by the netstat command and in the MIB-II "interfaces" table) and for CSU serial link connections (the things that T3 cables plug into). Since MIB-II has already defined "interfaces", let me call the T3 connections to a CSU "ports" for now. If there is a more widely accepted term, I'll use that instead. Suppose that we have a system with two CSUs, each of which supports two ports, plus an ethernet adapter. If you interpret the definitions in the current ds3 MIB literally, then you might get values like this: description ifIndex ds3CSUIndex ds3Index -------------- ------- -------------------- loopback 1 CSU #1 port #1 2 1 2 CSU #1 port #2 3 1 3 ethernet 4 CSU #2 port #1 5 2 5 CSU #2 port #2 6 2 6 The problem is that since ds3CSUIndex is used as a table index, its values must be unique. If I understand your intent correctly, then I'll suggest that what you'd really like to do is change the table index from ds3CSUIndex to ds3Index, leaving the current definitions just as they are, and then add a new variable for the "port" number. Then you might have something like this: description ifIndex ds3Index ds3CSUIndex ds3CSUPort -------------- ------- ------------------------------- loopback 1 CSU #1 port #1 2 2 1 1 CSU #1 port #2 3 3 1 2 ethernet 4 CSU #2 port #1 5 5 2 1 CSU #2 port #2 6 6 2 2 Since ds3CSUIndex and ds3CSUPort need not be unique values can be assigned that are meaningful for the CSUs. For example, CSUs often have a serial number stamped on them that is software-readable; this might be a good choice for ds3CSUIndex. And the connectors on the back of a CSU which supports multiple T3 links are usually labelled "0-3" or "1-4"; these numbers might be a good choice for ds3CSUPort. If this seems reasonable to you, then the remaining question is: What bureaucratic process is required to change the index of a table? And after that, is ds3NewLoopback any better than ds3Loopback? Ed ================================================================= Yes, I would like to change the INDEX of each table to inclue either just ds3Index or both ds3CSUIndex and ds3Index; thus leaving the description the same. However, did you see my message to Colm Bergin: ================================================== To: cbergin%dalitc@digi.lonestar.org, tacox@ginsu4, thumper!tob, trunk-mib@saffron.acc.com Subject: DS3 and DS1 RFCs Colm Bergin, Ted Brunner from Bellcore cc'ed me on his mail message to you about using the DS1/DS3 MIB to manage a multiplexor or a digital cross-connect. You were concerned that the MIBs were used only to manage a CSU. I am of the opinion that the DS1 MIB can be used to manage a DS1 interface -- on any device. To further manage a mux -- you may need other objects, but the DS1 MIB is the minimum subset of things you need to manage a device that has a DS1 interface. I am trying to change the mibs to suit that need. I would suggest you sign up to the trunk-mib@saffron.acc.com mailing list to hear the discussions on the DS1 and DS3 mibs. To do that send your email info to trunk-mib-request@saffron.acc.com We at Bellcore are doing exactly what I described above for our Switching System that supports SMDS. For example, our switch has DS3 and DS1 interfaces. On top of that interface runs the SMDS Interface Protocol or SIP. We support in our switch the DS1 and DS3 MIBs -- depending on the interface; and the SIP MIB -- see draft-ietf-snmp-smdssipmib-06.txt (or 07) in internet-drafts. So therefore, I see no reason that you could not use the DS1 MIB to manage a portion of your mux or digital cross connect system. Included is your original mail message and Ted's response for others to follow this arguement. Thanks. Tracy =========================================== Tracy A. Cox Bellcore NVC 1C-354 331 Newman Springs Rd. Red Bank, NJ 07701 tacox@sabre.bellcore.com email (908) 758-2107 vmail (908) 758-4177 fax =========================================== Subject: Help on T1 MIB Date: Thu, 06 Feb 92 14:22:59 -0500 From: tob@jeff.bellcore.com Colm Bergin- "The T1 mib" is rfc1232, and so when you receive it you will have what we've got, so far. It concentrates on error statistics associated with the transmission facility (eg. errored seconds, severly errored seconds, errored framing seconds) kept on a 15minute time base. There are also alarm states (red and yellow) and some minimum amount of descriptive stuff about the line (eg whether is ANSI-ESF or G704-CRC or ...) Now, as you have observed for the DS3 mib, this is kept by CSUs, and you want to manage a multiplexor and a digital cross connect. For that, this mib will not help you. There is a mailing list for folks interested in T1 and DS3 management (trunk-mib@saffron.acc.com) The request to join is probably (trunk-mib-request@saffron.acc.com) Try there. The silver lining here is that you may be interested in talking with other vendors to develop a mib for your line of equipment. This list is a good place to start looking for others. Since I haven't really done such a thing myself, I'm not qualified to suggest a game plan. But if you want to pursue this, I'd be interested in talking, because I have an interest in cross-connects in a different context - ATM switches. Ted Brunner Bellcore tob@thumper.bellcore.com MRE 2P-252 201/829-4678 445 South St. Morristown NJ 07960-1910 ------enclosed message--------- Dave, I just recently received the reference list you posted to the SNMP mailing list. I was hoping to find mention of work on a MIB relating to the management of T-1 multiplexors and digital cross connects, but in my ignorance, I couldn't identify such a document. I checked the DS-3 interface description, but it relates only to CSU's (I'm waiting to receive RFC-1232 on DS-1 interfaces). Do you know if the IETF is addressing management of such WAN devices? Thanks for any information, Colm Bergin Software Engineer Integrated Telecom Corp. Internet: cbergin%dalitc@digi.lonestar.org ----- End Included Message ----- ========================================================== What I would prefer to do is change the ds3CSUIndex to ds3EquipIndex (same for DS1 also). ds3EquipIndex is just an identifier of a piece of equipment the one or more DS3 Interfaces. Therefore, the DS1 MIB and the DS3 MIB would be used to monitor any type of DS1/3 interface. I think the ds3NewLoopback is more generic for managing just an interface. ds3SendCode still needs work. Let me stop here and let you digest all of this. What do you think? Are you following this long message? Tracy
- and again ..... Tracy Cox