Received: from cnri by ietf.org id aa13715; 3 Feb 97 19:38 EST Received: from thumper-7.bellcore.com by CNRI.Reston.VA.US id aa27411; 3 Feb 97 19:37 EST Received: from janus.3com.com (janus.3com.com [129.213.128.99]) by thumper.bellcore.com (8.8.5/8.7.3) with ESMTP id TAA16448 for ; Mon, 3 Feb 1997 19:18:36 -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 QAA00805; Mon, 3 Feb 1997 16:17:14 -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 QAA15199; Mon, 3 Feb 1997 16:16:15 -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 QAA13523; Mon, 3 Feb 1997 16:17:07 -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 QAA08766; Mon, 3 Feb 1997 16:17:12 -0800 (PST) Received: by sutter.NSD.3Com.COM id AA13725 (5.65c/IDA-1.4.4-910730); Mon, 3 Feb 1997 16:15:55 -0800 Date: Mon, 3 Feb 1997 16:15:55 -0800 From: Faye Ly Message-Id: <199702040015.AA13725@sutter.NSD.3Com.COM> To: kanaya.yoshihiro@nsc.cae.ntt.co.jp Subject: Re: "atmVclAddrTable" and "atmAddrVclTable" Cc: atommib@thumper.bellcore.com Kanaya, I am working very hard on the next draft of atm2MIB-07 and it should be coming out this week. The atmVclAddrBindTable and atmAddrVclTable are actually changed a lot in this new draft. Would you like to wait until the new draft and make your comments again? Thanks. -faye (408)764-6576 fayely@3com.com   Received: from cnri by ietf.org id aa24811; 11 Feb 97 5:26 EST Received: from thumper-7.bellcore.com by CNRI.Reston.VA.US id aa06742; 11 Feb 97 5:26 EST Received: from ornet.ornet.co.il (ornet.co.il [194.90.140.5]) by thumper.bellcore.com (8.8.5/8.7.3) with ESMTP id FAA13851 for ; Tue, 11 Feb 1997 05:05:45 -0500 (EST) Received: (from melman@localhost) by ornet.ornet.co.il (8.7.6/8.7.3) id MAA00765 for atommib@thumper.bellcore.com; Tue, 11 Feb 1997 12:05:26 +0200 (IST) From: David Melman Message-Id: <199702111005.MAA00765@ornet.ornet.co.il> Subject: RFC1595 SONET MIB question To: atommib@thumper.bellcore.com Date: Tue, 11 Feb 1997 12:05:26 +0200 (IST) X-Mailer: ELM [version 2.4ME+ PL21 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit I have a question about the status objects: sonetSectionCurrentStatus sonetLineCurrentStatus sonetPathCurrentStatus Would it be acceptable to have these objects reflect "failures" rather than "defects"? I.e. a failure would exist if the condition persists for 2.5 seconds, and is cleared if the condition is absent for 10 seconds. Thanks, David _________________________________________________________________________ David Melman ORNET Data Communications Tel: +972-4-9981314 Technologies Ltd. Fax: +972-4-9981315 A SIEMENS company email: melman@ornet.co.il smail: P.O.B 323 Carmiel 21613 Israel   Received: from cnri by ietf.org id aa05048; 11 Feb 97 9:53 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa12097; 11 Feb 97 9:53 EST Received: from shannon.tellabs.com (shannon.shannon.tellabs.com [138.111.193.100]) by thumper.bellcore.com (8.8.5/8.7.3) with ESMTP id JAA03417 for ; Tue, 11 Feb 1997 09:21:10 -0500 (EST) Received: from sensi.shannon.tellabs.com(really [138.111.197.42]) by shannon.tellabs.com via sendmail with smtp id for ; Tue, 11 Feb 1997 14:19:17 +0000 (GMT) (Smail-3.2 1996-Jul-4 #3 built 1996-Aug-11) Received: by sensi.shannon.tellabs.com (Smail3.1.29.1 #38) id m0vuJ3C-00004nC; Tue, 11 Feb 97 14:19 GMT Message-Id: Date: Tue, 11 Feb 97 14:19 GMT From: "Stuart J. Barr" To: atommib@thumper.bellcore.com Subject: AToM MIB - no Traffic Descriptor Cc: robertr@shannon.tellabs.com, bak@shannon.tellabs.com, barry@shannon.tellabs.com X-Sun-Charset: US-ASCII Hi All, I've a couple of queries regarding Traffic Descriptor types, as described in draft-ietf-atommib-atm2TC-05.txt and used in draft-ietf-atommib-atm1ng-02.txt, and subsequent proposals made on the AToM MIB mailing list by Kaj Tesink in Dec., appended below. The traffic descriptor type atmNoTrafficDescriptor has been deprecated, and I'm wondering the preferred configuration for best effort traffic, where a traffic descriptor is not actually required. It does not appear as though it is legal to set atmVclTransmitTrafficDescrIndex etc. to 0, according to the current description, so that no TD is referenced, and it no longer appears possible to indicate 'no traffic descriptor type'. What is the intention? Moreover, what is the relationship between service category and the new traffic descriptor types. If the new traffic descriptor types described below by Kaj are all encompasing, and will eventually be incorporated into an updated ILMI spec, would the service category then be deprecated? Thanks for any insights! Stuart <<< Here's the email from kaj I referenced above>>> ----- Begin Included Message ----- From cc.bellcore.com!kaj Tue Dec 3 16:50:11 1996 Date: Tue, 3 Dec 96 11:34:05 EST X-Station-Sent-From: eve.bellcore.com X-Sender: kaj@eve.bellcore.com Mime-Version: 1.0 To: atommib@thumper.bellcore.com, dawnxie@lucent.com From: Kaj Tesink Subject: Re: distinguish UBR.1 and UBR.2 Cc: George , Roger , Tim Dwight <0006078043@mcimail.com> At 02:25 PM 11/22/96 -0400, dxie@mtgbcs.mt.lucent.com wrote: >In Context Convetion of ATM Management document, several >ATM traffic descriptor object types are defined. Among them, >atmNoClpNoScr object type can represent both UBR.1 and >UBR.2 traffic type. Does anyone know why the document use one >object type to represent two different traffic types? And if some >application wants to distiguish UBR.1 and UBR.2 traffic, is there >any MIB object defined in AToM MIB do that? > >Thanks. > >-- Dawn Xie > Lucent Technologies Inc. > (908) 957-2066 > dawnxie@lucent.com > Thanks for flagging that Dawn. The historical reason for the current situation is compatibility with the ATMForum's ILMI. I did some shopping around on this issue and also talked with several ATMForum members. We tentatively agreed that this situation is not really correct and that it would be better to have separate traffic descriptors for CBR, UBR.1 and UBR.2. Attached is the gist of these conversations. It proposes to keep the current descriptor but apply it only to CBR (the change in semantics in practice seems minor and wouldnt merit deprecation). Then we introduce two new descriptors for UBR.1 and UBR.2. The proposal is then also to fix the ILMI later in a compatible way; an errata list for the ILMI is being maintained that can be used for this purpose. Any comments? Kaj ------------------------------------------------------------------------- > > >> >> > >> > Current ILMI mapping >> > >> > Traffic Descriptor Type Association >> > ----------------------- ----------- >> > atmfNoClpNoScr = CBR.1,UBR.1,UBR.2 >> > atmfNoClpScr = VBR.1 >> > atmfClpNoTaggingscr = VBR.2 >> > atmfClptTaggingScr = VBR.3 >> > atmfNoClpNoTaggingMcr = ABR >> > >> Proposed mapping >> >> Traffic Descriptor Type Association >> ----------------------- ----------- >> atmfNoClpNoScr = CBR.1 >> atmfNoClpScr = VBR.1 >> atmfClpNoTaggingScr = VBR.2 >> atmfClpTaggingScr = VBR.3 >> atmfNoClpNoTaggingMcr = ABR >> atmfNoClpNoTaggingNoScr = UBR.1 >> atmfClpTaggingNoScr = UBR.2 > > here's the revised text for the suggested revision of 1695: atmNoClpNoScr OBJECT-IDENTITY STATUS current DESCRIPTION "Indicates the CBR.1 Conformance Definition [13]. ! This traffic descriptor 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 Parameter 5: not used. This traffic descriptor type can be used for best effort traffic." ::= {atmTrafficDescriptorTypes 2} atmNoClpNoTaggingNoScr OBJECT-IDENTITY ! STATUS current ! DESCRIPTION ! "Indicates the UBR.1 Conformance Definition [13]. ! This traffic descriptor is for no 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: not used ! Parameter 3: not used ! Parameter 4: not used ! Parameter 5: not used." ! ::= {atmTrafficDescriptorTypes 9} ! atmClpTaggingNoScr2 OBJECT-IDENTITY ! STATUS current ! DESCRIPTION ! "Indicates the UBR.2 Conformance Definition [13]. ! 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: not used ! Parameter 3: not used ! Parameter 4: not used ! Parameter 5: not used." ! ::= {atmTrafficDescriptorTypes 10} ! _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ _/ _/ _/ 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 _/ _/ _/ _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ ----- End Included Message ----- ______________________________________________________________________ ___ ____ __ Stuart J. Barr Tellabs Ltd. (_ / /__) __, ,_ ,_ sbarr@shannon.tellabs.com Shannon ___). \_/. /__) (_/ / / Tel: +353 61 703010 Co. Clare Fax: +353 61 703333 Ireland   Received: from cnri by ietf.org id aa22434; 11 Feb 97 13:32 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa18888; 11 Feb 97 13:32 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 NAA12346 for ; Tue, 11 Feb 1997 13:09:49 -0500 (EST) Received: from joker (joker.bellcore.com) by tbird.cc.bellcore.com with SMTP id AA25637 (5.67b/IDA-1.5); Tue, 11 Feb 1997 10:04:34 -0500 Received: from nv-ktesink.cc.bellcore.com by joker (4.1/4.7) id AA10660; Tue, 11 Feb 97 10:06:14 EST Date: Tue, 11 Feb 97 10:06:14 EST X-Station-Sent-From: joker.bellcore.com Message-Id: <3.0.16.19970211100154.2d9fe026@joker.bellcore.com> X-Sender: kaj@joker.bellcore.com X-Mailer: Windows Eudora Pro Version 3.0 (16) To: "Stuart J. Barr" , atommib@thumper.bellcore.com From: Kaj Tesink Subject: Re: AToM MIB - no Traffic Descriptor Cc: robertr@shannon.tellabs.com, bak@shannon.tellabs.com, barry@shannon.tellabs.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Hi Stuart, During last SanJose meeting a small team met on a number of issues including this one. Mickey Spiegel volunteered to draft a consistent revision. This will be included in the next draft which will appear shortly. My understanding was that the service category would not be deprecated. kaj At 02:19 PM 2/11/97 GMT, Stuart J. Barr wrote: >Hi All, > >I've a couple of queries regarding Traffic Descriptor types, as >described in draft-ietf-atommib-atm2TC-05.txt and used in >draft-ietf-atommib-atm1ng-02.txt, and subsequent proposals made on the >AToM MIB mailing list by Kaj Tesink in Dec., appended below. > >The traffic descriptor type atmNoTrafficDescriptor has been deprecated, >and I'm wondering the preferred configuration for best effort traffic, >where a traffic descriptor is not actually required. It does not >appear as though it is legal to set atmVclTransmitTrafficDescrIndex >etc. to 0, according to the current description, so that no TD is >referenced, and it no longer appears possible to indicate 'no traffic >descriptor type'. What is the intention? > >Moreover, what is the relationship between service category and the >new traffic descriptor types. If the new traffic descriptor types >described below by Kaj are all encompasing, and will eventually be >incorporated into an updated ILMI spec, would the service category then >be deprecated? > >Thanks for any insights! > >Stuart > > ><<< Here's the email from kaj I referenced above>>> > >----- Begin Included Message ----- > >>From cc.bellcore.com!kaj Tue Dec 3 16:50:11 1996 >Date: Tue, 3 Dec 96 11:34:05 EST >X-Station-Sent-From: eve.bellcore.com >X-Sender: kaj@eve.bellcore.com >Mime-Version: 1.0 >To: atommib@thumper.bellcore.com, dawnxie@lucent.com >From: Kaj Tesink >Subject: Re: distinguish UBR.1 and UBR.2 >Cc: George , Roger , > Tim Dwight <0006078043@mcimail.com> > >At 02:25 PM 11/22/96 -0400, dxie@mtgbcs.mt.lucent.com wrote: >>In Context Convetion of ATM Management document, several >>ATM traffic descriptor object types are defined. Among them, >>atmNoClpNoScr object type can represent both UBR.1 and >>UBR.2 traffic type. Does anyone know why the document use one >>object type to represent two different traffic types? And if some >>application wants to distiguish UBR.1 and UBR.2 traffic, is there >>any MIB object defined in AToM MIB do that? >> >>Thanks. >> >>-- Dawn Xie >> Lucent Technologies Inc. >> (908) 957-2066 >> dawnxie@lucent.com >> > >Thanks for flagging that Dawn. The historical reason for the >current situation is compatibility with the ATMForum's ILMI. >I did some shopping around on >this issue and also talked with several ATMForum members. >We tentatively agreed that this situation is not really correct >and that it would be better to have separate traffic descriptors >for CBR, UBR.1 and UBR.2. > >Attached is the gist of these conversations. It proposes to >keep the current descriptor but apply it only to CBR (the change >in semantics in practice seems minor and wouldnt merit deprecation). >Then we introduce two new descriptors for UBR.1 and UBR.2. >The proposal is then also to fix the ILMI later in a compatible way; >an errata list for the ILMI is being maintained that can be used >for this purpose. > >Any comments? > >Kaj > >------------------------------------------------------------------------- >> >> >>> >>> > >>> > Current ILMI mapping >>> > >>> > Traffic Descriptor Type Association >>> > ----------------------- ----------- >>> > atmfNoClpNoScr = CBR.1,UBR.1,UBR.2 >>> > atmfNoClpScr = VBR.1 >>> > atmfClpNoTaggingscr = VBR.2 >>> > atmfClptTaggingScr = VBR.3 >>> > atmfNoClpNoTaggingMcr = ABR >>> > > >>> Proposed mapping >>> >>> Traffic Descriptor Type Association >>> ----------------------- ----------- >>> atmfNoClpNoScr = CBR.1 >>> atmfNoClpScr = VBR.1 >>> atmfClpNoTaggingScr = VBR.2 >>> atmfClpTaggingScr = VBR.3 >>> atmfNoClpNoTaggingMcr = ABR >>> atmfNoClpNoTaggingNoScr = UBR.1 >>> atmfClpTaggingNoScr = UBR.2 >> >> > > >here's the revised text for the suggested revision of 1695: > > atmNoClpNoScr OBJECT-IDENTITY > STATUS current > DESCRIPTION > "Indicates the CBR.1 Conformance Definition [13]. ! > This traffic descriptor 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 > Parameter 5: not used. > This traffic descriptor type can be used > for best effort traffic." > ::= {atmTrafficDescriptorTypes 2} > > atmNoClpNoTaggingNoScr OBJECT-IDENTITY ! > STATUS current ! > DESCRIPTION ! > "Indicates the UBR.1 Conformance Definition [13]. ! > This traffic descriptor is for no 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: not used ! > Parameter 3: not used ! > Parameter 4: not used ! > Parameter 5: not used." ! > ::= {atmTrafficDescriptorTypes 9} ! > > atmClpTaggingNoScr2 OBJECT-IDENTITY ! > STATUS current ! > DESCRIPTION ! > "Indicates the UBR.2 Conformance Definition [13]. ! > 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: not used ! > Parameter 3: not used ! > Parameter 4: not used ! > Parameter 5: not used." ! > ::= {atmTrafficDescriptorTypes 10} ! > > >_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ >_/ _/ >_/ 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 _/ >_/ _/ >_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ > > > >----- End Included Message ----- > >______________________________________________________________________ > ___ ____ __ Stuart J. Barr Tellabs Ltd. > (_ / /__) __, ,_ ,_ sbarr@shannon.tellabs.com Shannon > ___). \_/. /__) (_/ / / Tel: +353 61 703010 Co. Clare > Fax: +353 61 703333 Ireland > > _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ _/ _/ _/ 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 aa22469; 11 Feb 97 13:34 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa18944; 11 Feb 97 13:34 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 NAA12189 for ; Tue, 11 Feb 1997 13:05:25 -0500 (EST) Received: from joker (joker.bellcore.com) by tbird.cc.bellcore.com with SMTP id AA25252 (5.67b/IDA-1.5); Tue, 11 Feb 1997 09:55:59 -0500 Received: from nv-ktesink.cc.bellcore.com by joker (4.1/4.7) id AA10575; Tue, 11 Feb 97 09:57:40 EST Date: Tue, 11 Feb 97 09:57:40 EST X-Station-Sent-From: joker.bellcore.com Message-Id: <3.0.16.19970211095610.2d9fea00@joker.bellcore.com> X-Sender: kaj@joker.bellcore.com X-Mailer: Windows Eudora Pro Version 3.0 (16) To: David Melman , atommib@thumper.bellcore.com From: Kaj Tesink Subject: Re: RFC1595 SONET MIB question Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Hi David, At 12:05 PM 2/11/97 +0200, David Melman wrote: >I have a question about the status objects: > > sonetSectionCurrentStatus > sonetLineCurrentStatus > sonetPathCurrentStatus > >Would it be acceptable to have these objects reflect >"failures" rather than "defects"? > >I.e. a failure would exist if the condition persists for >2.5 seconds, and is cleared if the condition is absent >for 10 seconds. I can see the rationale for your proposal. But unless the current definition is really wrong and contradicts current implementation practice. I would be very hesitant to change the semantics of these objects: a) It would require deprecation and definition of new ones. Implementation feedback has not indicated any problems with these objects. b) I already submitted the draft to the NMAD for processing as Draft as per the conclusions of the SanJose meeting. Any opinions out there (especially based on implementation experience)? kaj > >Thanks, > >David > > _________________________________________________________________________ > David Melman ORNET Data Communications > Tel: +972-4-9981314 Technologies Ltd. > Fax: +972-4-9981315 A SIEMENS company > email: melman@ornet.co.il > smail: P.O.B 323 Carmiel 21613 Israel > > _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ _/ _/ _/ 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 aa25101; 11 Feb 97 14:14 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa20125; 11 Feb 97 14:14 EST Received: from portal.netedge.com (portal.netedge.com [199.170.8.2]) by thumper.bellcore.com (8.8.5/8.8.5) with SMTP id NAA14156 for ; Tue, 11 Feb 1997 13:52:12 -0500 (EST) Received: from NetEdge.COM by portal.netedge.com id AA17612; Tue, 11 Feb 97 13:40:10 EST Received: from raggedmtn.NetEdge.COM by NetEdge.COM id AA22480; Tue, 11 Feb 97 13:54:37 EST Received: by raggedmtn.NetEdge.COM (4.1/NECL-6.15) id AA25342; Tue, 11 Feb 97 13:41:59 EST From: Chris_Martin Message-Id: <9702111841.AA25342@NetEdge.COM> Subject: Re: AToM MIB - no Traffic Descriptor To: "Stuart J. Barr" Date: Tue, 11 Feb 97 13:41:58 EST Cc: atommib@thumper.bellcore.com In-Reply-To: ; from "Stuart J. Barr" at Feb 11, 97 2:19 pm X-Mailer: ELM [version 2.3 PL2] Stuart wrote: > > Hi All, > > I've a couple of queries regarding Traffic Descriptor types, as > described in draft-ietf-atommib-atm2TC-05.txt and used in > draft-ietf-atommib-atm1ng-02.txt, and subsequent proposals made on the > AToM MIB mailing list by Kaj Tesink in Dec., appended below. > > The traffic descriptor type atmNoTrafficDescriptor has been deprecated, > and I'm wondering the preferred configuration for best effort traffic, > where a traffic descriptor is not actually required. It does not [...] The only thing I could figure is that atmServiceCategory being set to ubr(6) implies "atmNoTrafficDescriptor." I'm not sure this is stated anywhere, but I guess it makes sense to do. Note that the DEFVALs of the discrete parameters are all 0 with ubr, so perhaps this was the intent. _____________________________________________________________________ _/ _/ _/_/_/_/ _/_/_/_/_/ _/_/_/_/ _/_/_/_/ _/_/_/_/ _/_/_/_/ _/_/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/_/_/ _/ _/_/_/ _/ _/ _/ _/_/ _/_/ _/ _/_/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/_/_/_/ _/ _/_/_/_/ _/_/_/_/ _/_/_/_/ _/_/_/_/ _____________________________________________________________________ Chris Martin INTERNET: martin@NetEdge.com NetEdge Systems PHONE: (919) 991-9253 P.O. Box 14993 FAX: (919) 991-9160 Research Triangle Park, NC 27709-4993   Received: from cnri by ietf.org id aa27096; 11 Feb 97 14:45 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa20863; 11 Feb 97 14:45 EST Received: from stilton.cisco.com (stilton.cisco.com [171.69.1.161]) by thumper.bellcore.com (8.8.5/8.8.5) with SMTP id OAA15622 for ; Tue, 11 Feb 1997 14:20:01 -0500 (EST) Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by stilton.cisco.com (8.6.12/8.6.5) with SMTP id LAA22203; Tue, 11 Feb 1997 11:19:28 -0800 From: "Michael H. Grobelch" Message-Id: <199702111919.LAA22203@stilton.cisco.com> To: "Stuart J. Barr" cc: grobelch@cisco.com, atommib@thumper.bellcore.com Subject: Re: AToM MIB - no Traffic Descriptor In-reply-to: Your message of "Tue, 11 Feb 97 14:19:00 GMT." Date: Tue, 11 Feb 97 11:19:28 PST >Date: Tue, 11 Feb 97 14:19 GMT >From: sbarr@shannon.tellabs.com (Stuart J. Barr) >To: atommib@thumper.bellcore.com >Subject: AToM MIB - no Traffic Descriptor >Cc: robertr@shannon.tellabs.com, bak@shannon.tellabs.com, > barry@shannon.tellabs.com >X-Sun-Charset: US-ASCII >Content-Length: 7894 > >Hi All, > >I've a couple of queries regarding Traffic Descriptor types, as >described in draft-ietf-atommib-atm2TC-05.txt and used in >draft-ietf-atommib-atm1ng-02.txt, and subsequent proposals made on the >AToM MIB mailing list by Kaj Tesink in Dec., appended below. > >The traffic descriptor type atmNoTrafficDescriptor has been deprecated, >and I'm wondering the preferred configuration for best effort traffic, >where a traffic descriptor is not actually required. It does not >appear as though it is legal to set atmVclTransmitTrafficDescrIndex >etc. to 0, according to the current description, so that no TD is >referenced, and it no longer appears possible to indicate 'no traffic >descriptor type'. What is the intention? I believe the intention is that you always, at least, specify some value for PCR0+1. How meaningful this is depends on the implementation. For example, you might want to shape to the PCR in an end-system. > >Moreover, what is the relationship between service category and the >new traffic descriptor types. If the new traffic descriptor types >described below by Kaj are all encompasing, and will eventually be >incorporated into an updated ILMI spec, would the service category then >be deprecated? Service category is the first choice to make, then you specify a descriptor compatible with the service category. Service Category is present in ILMI 4.0, is basic to TM, and I believe shows no sign of being discarded as a concept. Mike >Date: Tue, 3 Dec 96 11:34:05 EST >X-Station-Sent-From: eve.bellcore.com >X-Sender: kaj@eve.bellcore.com >Mime-Version: 1.0 >To: atommib@thumper.bellcore.com, dawnxie@lucent.com >From: Kaj Tesink >Subject: Re: distinguish UBR.1 and UBR.2 >Cc: George , Roger , > Tim Dwight <0006078043@mcimail.com> > >At 02:25 PM 11/22/96 -0400, dxie@mtgbcs.mt.lucent.com wrote: >>In Context Convetion of ATM Management document, several >>ATM traffic descriptor object types are defined. Among them, >>atmNoClpNoScr object type can represent both UBR.1 and >>UBR.2 traffic type. Does anyone know why the document use one >>object type to represent two different traffic types? And if some >>application wants to distiguish UBR.1 and UBR.2 traffic, is there >>any MIB object defined in AToM MIB do that? >> >>Thanks. >> >>-- Dawn Xie >> Lucent Technologies Inc. >> (908) 957-2066 >> dawnxie@lucent.com >> > >Thanks for flagging that Dawn. The historical reason for the >current situation is compatibility with the ATMForum's ILMI. >I did some shopping around on >this issue and also talked with several ATMForum members. >We tentatively agreed that this situation is not really correct >and that it would be better to have separate traffic descriptors >for CBR, UBR.1 and UBR.2. > >Attached is the gist of these conversations. It proposes to >keep the current descriptor but apply it only to CBR (the change >in semantics in practice seems minor and wouldnt merit deprecation). >Then we introduce two new descriptors for UBR.1 and UBR.2. >The proposal is then also to fix the ILMI later in a compatible way; >an errata list for the ILMI is being maintained that can be used >for this purpose. > >Any comments? > >Kaj > >------------------------------------------------------------------------- >> >> >>> >>> > >>> > Current ILMI mapping >>> > >>> > Traffic Descriptor Type Association >>> > ----------------------- ----------- >>> > atmfNoClpNoScr = CBR.1,UBR.1,UBR.2 >>> > atmfNoClpScr = VBR.1 >>> > atmfClpNoTaggingscr = VBR.2 >>> > atmfClptTaggingScr = VBR.3 >>> > atmfNoClpNoTaggingMcr = ABR >>> > > >>> Proposed mapping >>> >>> Traffic Descriptor Type Association >>> ----------------------- ----------- >>> atmfNoClpNoScr = CBR.1 >>> atmfNoClpScr = VBR.1 >>> atmfClpNoTaggingScr = VBR.2 >>> atmfClpTaggingScr = VBR.3 >>> atmfNoClpNoTaggingMcr = ABR >>> atmfNoClpNoTaggingNoScr = UBR.1 >>> atmfClpTaggingNoScr = UBR.2 >> >> > > >here's the revised text for the suggested revision of 1695: > > atmNoClpNoScr OBJECT-IDENTITY > STATUS current > DESCRIPTION > "Indicates the CBR.1 Conformance Definition [13]. ! > This traffic descriptor 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 > Parameter 5: not used. > This traffic descriptor type can be used > for best effort traffic." > ::= {atmTrafficDescriptorTypes 2} > > atmNoClpNoTaggingNoScr OBJECT-IDENTITY ! > STATUS current ! > DESCRIPTION ! > "Indicates the UBR.1 Conformance Definition [13]. ! > This traffic descriptor is for no 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: not used ! > Parameter 3: not used ! > Parameter 4: not used ! > Parameter 5: not used." ! > ::= {atmTrafficDescriptorTypes 9} ! > > atmClpTaggingNoScr2 OBJECT-IDENTITY ! > STATUS current ! > DESCRIPTION ! > "Indicates the UBR.2 Conformance Definition [13]. ! > 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: not used ! > Parameter 3: not used ! > Parameter 4: not used ! > Parameter 5: not used." ! > ::= {atmTrafficDescriptorTypes 10} ! > > >_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ >_/ _/ >_/ 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 _/ >_/ _/ >_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ > > > >----- End Included Message ----- > >______________________________________________________________________ > ___ ____ __ Stuart J. Barr Tellabs Ltd. > (_ / /__) __, ,_ ,_ sbarr@shannon.tellabs.com Shannon > ___). \_/. /__) (_/ / / Tel: +353 61 703010 Co. Clare > Fax: +353 61 703333 Ireland   Received: from cnri by ietf.org id aa15534; 13 Feb 97 16:12 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa26554; 13 Feb 97 16:11 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 PAA27402 for ; Thu, 13 Feb 1997 15:37:07 -0500 (EST) Received: from joker (joker.bellcore.com) by tbird.cc.bellcore.com with SMTP id AA02679 (5.67b/IDA-1.5 for ); Thu, 13 Feb 1997 15:37:03 -0500 Received: from nv-ktesink.cc.bellcore.com by joker (4.1/4.7) id AA00956; Thu, 13 Feb 97 15:38:36 EST Date: Thu, 13 Feb 97 15:38:36 EST X-Station-Sent-From: joker.bellcore.com Message-Id: <3.0.16.19970213153708.3027a382@joker.bellcore.com> X-Sender: kaj@joker.bellcore.com X-Mailer: Windows Eudora Pro Version 3.0 (16) To: internet-drafts@CNRI.Reston.VA.US, atommib@thumper.bellcore.com From: Kaj Tesink Subject: Posting Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_855877031==_" --=====================_855877031==_ Content-Type: text/plain; charset="us-ascii" Hi Cynthia, Please post the attached as draft-ietf-atommib-atm1ng-03.txt Thanks, Kaj ------------------------------------------------- atommibbers, attached is the new version of the 1695ng spec. the new versions of the suppl mib and atmtc mib will follow shortly; we're doing some last moment consistencies with the atmf/ilmi. the changes in 1695ng follow mickey's comments of 12/10 (see extract below; the more significant one is deprecation of atmInterfaceAdminAddress and replacement of that with an atmInterfaceSubscrAddress. since the changes are minor, i plan to give the 1695ng to the NM-AD in two weeks to recommend as Draft as per the san jose ietf, unless i hear a major objection. kaj ---------------------------------------------------- Change Log 1695ng The following changes were made for the version dated January 7, 1997: Extract Mickey Spiegel mail 12/10/97 10) Section 5.3.1, last sentence, could change if CBR.1, VBR.1, or UBR.2 codepoints are added (see items 4-6). Resolution: sentence deleted. 11) Section 5.3.4: For PVCs, the service category is configured separately at each switch, so it is not ensured that the service category will be the same for all VCLs (or VPLs). The second sentence should read "When properly configured, VCLs (or VPLs) concatenated to form a VCC (or VPC) should all have the same service category as that of the VCC (or VPC)". Resolution: done 12) Shouldn't there be a REVISION clause? Resolution: done 13) In the description of this ATM MIB module, should another group be mentioned for the ATM Traffic Descriptor? 14) For first four objects of atmInterfaceConfEntry, PVC -> PVPC or PVCC, SVC -> SVPC or SVCC, the former for VPCs and the latter for VCCs. Resolution: done 17) Can atmInterfaceAdminAddress change from `read-only' in RFC 1695 to `read-write' in this MIB, without changing the OID? >> James to propose replacement object with title changed to atmInterfaceSubscriberId or something similar. Existing object to be deprecated. Resolution of this item is related to item 30. Resolution: deprecated - new subscrAddress defined. 18) atmVplEntry and atmVclEntry DESCRIPTIONs Another error check should be added to item (2b): If the transmit and receive service categories are inconsistent, the agent should refuse the request. Resolution: done 20) atmVpCrossConnectRowStatus and atmVcCrossConnectRowStatus DESCRIPTIONs The following text should be removed, since it is inconsistent with the existence of DEFVALs for the atmV[p|c]CrossConnectAdminStatus: This object cannot be set to `active' unless the following columnar object exists in this row: atmV[p|c]CrossConnectAdminStatus. Resolution: done 21) No dash in "PNNI", Wrong assigned number and date, should be "af-pnni-0055.000, March 1996". Resolution: done 22) Any need to distinguish UNI from NNI? >> See proposed resolution to item 2. The following changes were made for the version of the document dated October 22, 1996. 0 Removed an IMPORT loop with the ATM TC MIB. 0 atmInterfaceAddressType (deprecated) removed from conformance. 0 Removed compliance/conformance clause inconsistency. 0 Included atmTrafficDescrParamIndexNext 0 Reorganized the conformance/compliance statements to separate PVC/SVC/general applicability. The following changes were made for the version of the document dated June 26, 1996. These changes were made as a result of the comments provided by the AToM MIB Working Group on RFC1695. 0 atmConnKind inserted 0 Soft PVC text /P-NNI reference fixed. 0 Sect. 6.3.1 sentence "including one for best effort" removed (misleading and in error). 0 Sect. 6.3.4 - Fixed issue that Vls may not have the same service category. 0 atmInterfaceAddressType is deprecated - rationale: redundant. 0 atmInterfaceAdminAddress DESCRIPTION fixed. 0 atmVpl/VclRowStatus modified for consistency with DEFVALs of the TrafficDescrIndices. 0 atmVccAalType has DEFVAL {aal5} 0 Editorials, references, etc. fixed. Still to be done: 0 Conformance statement updates & PVC/SVC conformance requirements. The following changes were made for the version of the document dated April 6, 1996. These changes were made as a result of the comments provided by the AToM MIB Working Group on RFC1695. 0 Remove IfIndex TC. Move AtmTrafficDescrParamIndex and all OBJECT IDENTITIES to a separate document. Import InterfaceIndex, AtmVpIdentifier, AtmVcIdentifier, AtmTrafficDescrParamIndex, AtmConnCastType, AtmVorXAdminStatus, AtmVorXOperStatus, AtmVorXLastChange FROM ATM-TC-MIB and simplify DESCRIPTION clauses accordingly. 0 Fix AtmTrafficDescrParamIndex=0 case (in ATM-TC-MIB) - i.e., no row is identified. 0 Clarify that the ifIndex value in the atmInterfaceConfTable as well as in the DS3PLCP and TC Tables refers to the ATM interface. 0 Clarify that Vxl/XConnectOperStatus goes down/unknown if underlying ATM goes down/unknown. 0 Replace atmTrafficQosClass with atmServiceCategory. Leading text regarding QoS is fixed. 0 Introduce new objects for atmInterfaceMaxBits/Vxcs etc. and introduce a leading text section on this include figure. 0 Fix Conformance statement according with additions. 0 Extended 4.2 with a descriptive line on SPVCs since we use that in the interface table. 0 DEFVAL atmVpl/VclTransmit/ReceiveDescrIndex, atmVclAdminStatus, atmVcCrossConnectRowStatus. 0 Clarify the implication of the existence of the atmVccAal5 objects (see atmVclRowStatus). 0 Introduce atmVplCastType and atmVclCastType. Fix procedure description regarding use of atmVxlCastType 0 Email 1/10/95 on chicken&egg problem - included a qualification in item (3) of atmVclEntry 0 Some editorials. Still to be done: 0 Is there an issue on what atmInterfaceAddressType refers to (refers to ifPhysAddr or atmInterfaceAdminAddr - what to do if there is no address, etc.). 0 Fix references --=====================_855877031==_ Content-Type: text/plain; charset="us-ascii" Content-Disposition: attachment; filename="POST1695.RFC" Definitions of Managed Objects for ATM Management January 8, 1997 Kaj Tesink (editor) Bell Communications Research 331 Newman Springs Road Red Bank, NJ 07701 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 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". draft ATM Management Objects January 8, 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. 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. 3. The SNMPv2 Network Management Framework The SNMPv2 Network Management Framework consists of four major components. They are: 0 RFC 1902 [1] which defines the SMI, the mechanisms used for describing and naming objects for the purpose of management. 0 STD 17, RFC 1213 [2] defines MIB-II, the core set of managed objects for the Internet suite of protocols. 0 RFC 1157 [3] and RFC1905 [4] 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. Textual Conventions used in this MIB are defined in [7] and [8]. Expires 7/8/97 [Page 2] draft ATM Management Objects January 8, 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. Expires 7/8/97 [Page 3] draft ATM Management Objects January 8, 1997 5. ATM Terminology Some basic ATM terminologies are described in this section to facilitate defining the ATM managed objects. 5.1. VCL/VPL and VCC/VPC There are two distinct types of ATM virtual connections: Virtual Channel Connections (VCCs) and Virtual Path Connection (VPCs). As shown in Figures 1 and 2, ATM virtual connections consist of concatenated series of virtual links which forms a path between two end points, with each concatenation occurring at an ATM switch. Virtual links of VCCs are called Virtual Channel Links (VCLs). Virtual links of VPCs are called Virtual Path Links (VPLs). The VCI and VPI fields in the ATM cell header associate each cell of a VCC with a particular VCL over a given physical link. The VPI field in the ATM cell header associates each cell of a VPC with a particular VPL over a given physical link. Switches route cells between VCLs (or VPLs) via a cross-connect function according to the cells' VCI/VPI (or VPI) values. <-----------------------VCC--------------------------> ------------ ----------- |ATM | |ATM | |X-Connect | |X-Connect | VCL1 |Point | VCL2 |Point | VCL3 O---------|----X-----|-------|-----|----X-----|-------O | | | | ------------ ------------ ATM Switch ATM Switch Figure 1: Virtual Channel Links and Virtual Channel Connection Expires 7/8/97 [Page 4] draft ATM Management Objects January 8, 1997 <-----------------------VPC--------------------------> ------------ ----------- |ATM | |ATM | |X-Connect | |X-Connect | VPL1 |Point | VPL2 |Point | VPL3 O---------|----X-----|-------|-----|----X-----|-------O | | | | ------------ ------------ ATM Switch ATM Switch Figure 2: Virtual Path Links and Virtual Path Connection A single ATM end-system or switch does not support the whole end-to-end span of a VCC (or VPC). Rather, multiple ATM end- systems and/or switches each support one piece of the VCC (or VPC). That is, each ATM end-system at one end of the VCC/VPC supports its end of the VCC/VPC plus the VCLs or VPLs on its external interfaces, and each switch through which the VCC/VPC passes, supports the multiple VCLs/VPLs on that switch's external interfaces and the cross-connection of those VCLs/VPLs through that switch. Thus, the end-to-end management of a VCC or VPC is achieved only by appropriate management of its individual pieces in combination. Note that for management purposes, an ATM network may be viewed as a large distributed switch by hiding all the network's internal connectivity as being internal to the distributed switch (as shown in Figure 2a). This model may for example be used for Customer Network Management (CNM) purposes. Expires 7/8/97 [Page 5] draft ATM Management Objects January 8, 1997 <---------------------VCC---------------------------> -------------------------------------- | | | ---------- ---------- | | | ATM | | ATM | | VCL1 | | Switch | | Switch | | VCL3 O-------|-|--------|------/-------|--------|-|------O | | | | | | | ---------- ---------- | | | | ATM Network | -------------------------------------- Figure 2a: ATM Network modeled as a large distributed switch A VCC has a set of traffic characteristics (i.e., bandwidth parameters, service category parameters, etc.). VCLs inherit their traffic characteristics from the VCC of which they are a part. VCCs are bi-directional by definition. However, the traffic parameters in the two directions of a connection can be symmetric or asymmetric, i.e., the two directions can have the same or different traffic flows. A uni-directional traffic flow across a VCC is achieved by assigning a zero bandwidth in one direction. Note that in addition to the bandwidth required by the user traffic flow, bandwidth is also required for OAM cell flows, even for the zero-bandwidth direction of a uni-directional connection. These same principles apply to VPCs. 5.2. PVC, SVC and Soft PVC A Permanent Virtual Connection (PVC) is a provisioned VCC or VPC. A Switched Virtual Connection (SVC) is a switched VCC or VPC that is set up in real-time via call set-up signaling procedures. A PVC (or an SVC) can be a point-to-point, point-to-multipoint, or multipoint-to-multipoint VCC or VPC. A Soft PVC is a connection of which portions are switched, while other portions are permanent (see Figure 3 and [11]). +--------+ +--------+ +--------+ Expires 7/8/97 [Page 6] draft ATM Management Objects January 8, 1997 pvc| ATM |svc svc | ATM |svc svc | ATM |pvc ----| Switch |-----------| Switch |-----------| Switch |---- +--------+ +--------+ +--------+ Figure 3: An example of a Soft PVC 5.3. Traffic Management Parameters 5.3.1. Traffic Policing and Traffic Shaping Parameters In order to allocate resources fairly among different users, some networks police traffic at resource access points. The traffic enforcement or policing taken at a UNI is called Usage Parameter Control (UPC) and is activated on an incoming VCL or VPL as shown in Figure 4. The use of the traffic enforcer at the ingress of the connection is to make sure that the user traffic does not exceed the negotiated traffic parameters such as the peak cell rate associated with a specific traffic descriptor type. ---------- ---------- UNI | ATM | NNI | ATM | UNI | | switch | | | switch | | O<---|---->X(UPC) |<----|------>| (UPC)X<-----|--->O | VCL | | | VCL | | VCL | ---------- ---------- Figure 4: An Example of a UPC In addition, traffic shaping may be performed on an outgoing VPL or VCL at a given ATM interface. The function of the ATM traffic shaper either at the source or an egress point of the connection is to smooth the outgoing cell traffic inter- arrival time. If policing or shaping is not performed then the policing or shaping algorithm is not activated. 5.3.2. Cell Loss Priority To prioritize traffic during resource congestion, ATM cells are assigned one of the two types of Cell Loss Priority (CLP), CLP=0 and CLP=1. ATM cells with CLP=0 have a higher priority Expires 7/8/97 [Page 7] draft ATM Management Objects January 8, 1997 in regard to cell loss than ATM cells with CLP=1. Therefore, during resource congestions, CLP=1 cells are dropped before any CLP=0 cell is dropped. 5.3.3. QoS Class RFC1695 specified that one of a number of Quality of Service (QoS) classes is assigned to a VCC or VPC by associating the object atmTrafficQoSClass with each VCL or VPL. However, new insights in ATM traffic management have caused this object to be deprecated. 5.3.4. Service Category Replacing QoS Class, VPLs and VCLs are qualified in terms of their service category (atmServiceCategory). When properly configured, VCLs (or VPLs) concatenated to form a VCC (or VPC) will all have the same service category class as that of the VCC (or VPC). 5.4. Max Active and Max Current VPI and VCI Bits A manager may wish to configure the maximum number of VPI and VCI bits that can be used to identify VPIs and VCIs on a given ATM interface. This value can be less than or equal to the maximum number of bits supported by the interface hardware, and is referred to in the MIB as the Max Active VPI Bits and Max Active VCI Bits. However, a manager may not be able to configure the Max Active Bits on both ends of an ATM link. For example, the manager may not be allowed write access to the peer's MIB, or there may be hardware limitations on the peer device. Therefore, the two ATM devices may use ILMI to negotiate "Max Current" VPI and VCI bits, which is the maximum number of bits that both interfaces are willing to support. This is illustrated in Figure 5. The relationship between the different parameters is illustrated in Figure 6. Note that if ILMI negotiation is not supported, then the devices have no choice but to use the configured MaxActive bits, and assume that it has been configured to the same value on both ends of the link. Expires 7/8/97 [Page 8] draft ATM Management Objects January 8, 1997 +--------+ +--------+ +--------+ | ATM | IF a IF b | ATM | IF c IF d | ATM | | Device |--------------| Device |--------------| Device | +--------+ +--------+ +--------+ IF a: Max Active VPI Bits = 6 (configured) Max Current VPI Bits = 6 (negotiated) IF b: Max Active VPI Bits = 8 (configured) Max Current VPI Bits = 6 (negotiated) IF c: Max Active VPI Bits = 8 (configured) Max Current VPI Bits = 8 (negotiated) IF d: Max Active VPI Bits = 8 (configured) Max Current VPI Bits = 8 (negotiated) (between IF a and IF b, the minimum of the two configured "Max Active VPI Bits" is 6, so both interfaces set their "Max Current VPI Bits" to 6. Since IF c and IF d both are configured with "Max Active VPI Bits" of 8, they set their "Max Current VPI Bits" to 8.) Figure 5 MSB LSB +----------------------------------------------------+ | | | | | +----------------------------------------------------+ ^ ^ ^ ^ | | | | Max bits Max Bits Max Max supported supported Active (config.) current (negotiated) by MIB by h/w Bits Bits Figure 6 6. Overview ATM management objects are used to manage ATM interfaces, ATM virtual links, ATM cross-connects, AAL5 entities and AAL5 connections supported by ATM hosts, ATM switches and ATM Expires 7/8/97 [Page 9] draft ATM Management Objects January 8, 1997 networks. This section provides an overview and background of how to use this MIB and other potential MIBs for this purpose. The purpose of this memo is primarily to manage ATM PVCs. ATM SVCs are also represented by the management information in this MIB. However, full management of SVCs may require additional capabilities which are beyond the scope of this memo. 6.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 and interface management [2][5], the DS3 or SONET MIBs for management of physical interfaces, and, as appropriate, MIB modules for applications that make use of ATM, such as SMDS. These MIB modules are outside the scope of this specification. The current specification of this ATM MIB is based on SNMPv2. 6.2. Structure of the MIB The managed ATM objects are arranged into the following groups: (1) ATM interface configuration group (2) ATM interface DS3 PLCP group (3) ATM interface TC Sublayer group (4) ATM interface virtual link (VPL/VCL) configuration groups (5) ATM VP/VC cross-connect groups (6) AAL5 connection performance statistics group Note that, managed objects for activation/deactivation of OAM cell flows and ATM traps notifying virtual connection or virtual link failures are outside the scope of this memo. 6.3. ATM Interface Configuration Group This group contains information on ATM cell layer configuration of local ATM interfaces on an ATM device in addition to the information on such interfaces contained in the ifTable. Expires 7/8/97 [Page 10] draft ATM Management Objects January 8, 1997 6.4. ATM Interface DS3 PLCP and TC Layer Groups These groups provide performance statistics of the DS3 PLCP and TC sublayer of local ATM interfaces on a managed ATM device. DS3 PLCP and TC sublayer are currently used to carry ATM cells respectively over DS3 and SONET transmission paths. 6.5. ATM Virtual Link and Cross-Connect Groups ATM virtual link and cross-connect groups model bi-directional ATM virtual links and ATM cross-connects. The ATM VP/VC link groups are implemented in an ATM host, ATM switch and ATM network. The ATM switch and ATM network also implement the ATM VP/VC cross-connect groups. Both link and cross-connect groups are implemented in a carrier's network for Customer Network Management (CNM) purposes. The ATM virtual link groups are used to create, delete or modify ATM virtual links in an ATM host, ATM switch and ATM network. ATM virtual link groups along with the cross-connect groups are used to create, delete or modify ATM cross-connects in an ATM switch or ATM network (e.g., for CNM purposes). 7. Application of MIB II to ATM 7.1. The System Group For the purposes of the sysServices object in the System Group of MIB II [2], ATM is a data link layer protocol. Thus, for ATM switches and ATM networks, sysServices will have the value "2". 7.2. The Interface Group The Interfaces Group of MIB II defines generic managed objects for managing interfaces. This memo contains the media- specific extensions to the Interfaces Group for managing ATM interfaces. This memo assumes the interpretation of the Interfaces Group to be in accordance with [5] which states that the interfaces table (ifTable) contains information on the managed resource's interfaces and that each sub-layer below the internetwork layer of a network interface is considered an interface. Expires 7/8/97 [Page 11] draft ATM Management Objects January 8, 1997 Thus, the ATM cell layer interface is represented as an entry in the ifTable. This entry is concerned with the ATM cell layer as a whole, and not with individual virtual connections which are managed via the ATM-specific managed objects specified in this memo. The inter-relation of entries in the ifTable is defined by Interfaces Stack Group defined in [5]. 7.2.1. Support of the ATM Cell Layer by ifTable Some specific interpretations of ifTable for the ATM cell layer follow. Expires 7/8/97 [Page 12] draft ATM Management Objects January 8, 1997 Object Use for the generic ATM layer ====== ============================= ifIndex Each ATM port is represented by an ifEntry. ifDescr Description of the ATM interface. ifType The value that is allocated for ATM is 37. ifSpeed The total bandwidth in bits per second for use by the ATM layer. ifPhysAddress The interface's address at the ATM protocol sublayer; the ATM address which would be used as the value of the Called Party Address Information Element (IE) of a signalling message for a connection which either: - would terminate at this interface, or - for which the Called Party Address IE would need to be replaced by the Called Party SubAddress IE before the message was forwarded to any other interface. For an interface on which signalling is not supported, then the interface does not necessarily have an address, but if it does, then ifPhysAddress is the address which would be used as above in the event that signalling were supported. If the interface has multiple such addresses, then ifPhysAddress is its primary address. If the interface has no addresses, then ifPhysAddress is an octet string of zero length. Address encoding is as per [9]. Note that addresses assigned for purposes other than those listed above (e.g., an address associated with the service provider side of a public network UNI) may be represented through atmInterfaceSubscrAddress. ifAdminStatus See [5]. ifOperStatus Assumes the value down(2) if the ATM cell layer or any layer below that layer is down. ifLastChange See [5]. Expires 7/8/97 [Page 13] draft ATM Management Objects January 8, 1997 ifInOctets The number of received octets over the interface, i.e., the number of received, assigned cells multiplied by 53. ifOutOctets The number of transmitted octets over the interface, i.e., the number of transmitted, assigned cells multiplied by 53. ifInErrors The number of cells dropped due to uncorrectable HEC errors. ifInUnknownProtos The number of received cells discarded during cell header validation, including cells with unrecognized VPI/VCI values, and cells with invalid cell header patterns. If cells with undefined PTI values are discarded, they are also counted here. ifOutErrors See [5]. ifName Textual name (unique on this system) of the interface or an octet string of zero length. ifLinkUpDownTrapEnable Default is disabled (2). ifConnectorPresent Set to false (2). ifHighSpeed See [5]. ifHCInOctets The 64-bit version of ifInOctets; supported if required by the compliance statements in [5]. ifHCOutOctets The 64-bit version of ifOutOctets; supported if required by the compliance statements in [5]. ifAlias The non-volatile 'alias' name for the interface as specified by a network manager. 8. Support of the AAL3/4 Based Interfaces For the management of AAL3/4 CPCS layer, see [6]. Expires 7/8/97 [Page 14] draft ATM Management Objects January 8, 1997 9. Support of the AAL5 Managed Objects Support of AAL5 managed objects in an ATM switch and ATM host are described below. 9.1. Managing AAL5 in a Switch Managing AAL5 in a switch involves: (1) performance management of an AAL5 entity as an internal resource in a switch (2) performance management of AAL5 per virtual connection AAL5 in a switch is modeled as shown in Figure 7 and 8. AAL5 will be managed in a switch for only those virtual connections that carry AAL5 and are terminated at the AAL5 entity in the switch. Note that, the virtual channels within the ATM UNIs carrying AAL5 will be switched by the ATM switching fabric (termed as ATM Entity in the figure) to the virtual channels on a proprietary internal interface associated with the AAL5 process (termed as AAL5 Entity in the figure). Therefore, performance management of the AAL5 resource in the switch will be modeled using the ifTable through an internal (pseudo-ATM) virtual interface and the AAL5 performance management per virtual connection will be supported using an additional AAL5 connection table in the ATM MIB. The association between the AAL5 virtual link at the proprietary virtual, internal interface and the ATM virtual link at the ATM interface will be derived from the virtual channel cross-connect table and the virtual channel link table in the ATM MIB. Expires 7/8/97 [Page 15] draft ATM Management Objects January 8, 1997 ___________________________ | | | ============= | | | AAL5 | | | | Entity | | | ============= | | | | | -----Prop. Virtual Interface | | | | ============= | | | ATM | | | | Entity | | | ============= | |_____|__|__|__|__|_______| | | | | | ---------------- ATM UNIs | | | | | | | | | | v v v v v Figure 7: Model of an AAL5 Entity in a Switch __________________ | | | AAL5 | |________________| | | | Prop. Virtual | | Interface | |________________| Figure 8: AAL5 Entity's Interface Stack in a Switch 9.2. Managing AAL5 in a Host Managing AAL5 in a host involves managing the AAL5 sublayer interface as shown in Figure 9 and 10. The AAL5 sublayer is stacked directly over the ATM sublayer. The ifTable is applied to the AAL5 sublayer as defined in Section 10.3. Expires 7/8/97 [Page 16] draft ATM Management Objects January 8, 1997 ___________________________ | | | ============= | | | AAL5 | | | | Entity | | | ============= | | | ATM | | | | Entity | | | ============= | |___________|_____________| | __|__ ATM UNI | | v Figure 9: Model of an AAL5 Entity in a Host __________________ | | | AAL5 | |________________| | | | ATM Layer | |________________| | | | Physical Layer| |________________| Figure 10: AAL5 Entity's Interface Stack in a Host Expires 7/8/97 [Page 17] draft ATM Management Objects January 8, 1997 9.3. Support of AAL5 by ifTable The AAL5 entity in an ATM device (e.g., switch or host) is managed using the ifTable. There are additional counters specified for AAL5 than those specified in the ATM B-ICI document [10]. Specific interpretations of ifTable for the AAL5 CPCS layer are as follows. Object Use for AAL5 CPCS layer entity ====== ============================== ifIndex Each AAL5 entity is represented by an ifEntry. ifDescr Description of the AAL5 entity. ifType The value that is allocated for AAL5 is 49. ifMtu Set to the largest PDU size for the AAL5 CPCS layer that can be processed by the AAL5 entity. ifSpeed Set to 0. ifPhysAddress An octet string of zero length. ifAdminStatus See [5]. ifOperStatus Assumes the value down(2) if the AAL5 or any layer below that layer is down. ifLastChange See [5]. ifInOctets The number of received AAL5 CPCS PDU octets. ifOutOctets The number of AAL5 CPCS PDU octets transmitted. ifInUcastPkts The number of received AAL5 CPCS PDUs passed to a higher-layer. ifOutUcastPkts The number of AAL5 CPCS PDUs received from a higher-layer for transmission. [Note: The number of AAL5 PDUs actually transmitted is the number received from a higher-layer for transmission minus any which Expires 7/8/97 [Page 18] draft ATM Management Objects January 8, 1997 are counted by ifOutErrors and ifOutDiscards.] ifInErrors Number of errored AAL5 CPCS PDUs received. The types of errors counted include CRC-32 errors, SAR time-out errors, and oversized SDU errors. ifInUnknownProtos Set to 0. ifInDiscards Number of received AAL5 CPCS PDUs discarded. Possible reason may be input buffer overflow. ifOutErrors Number of AAL5 CPCS PDUs that could not be transmitted due to errors. ifOutDiscards Number of AAL5 CPCS PDUs received for transmission that are discarded. Possible reason may be output buffer overflow. ifInMulticastPkts Set to 0. ifInBroadcastPkts Set to 0. ifOutMulticastPkts Set to 0. ifOutBroadcastPkts Set to 0. ifName Textual name (unique on this system) of the AAL5 entity or an octet string of zero length. ifHighSpeed Set to 0. ifConnectorPresent Set to false (2). ifPromiscuousMode Set to false(2). ifLinkUpDownTrapEnable Default is disabled (2). ifAlias The non-volatile 'alias' name for the interface as specified by a network manager. Expires 7/8/97 [Page 19] draft ATM Management Objects January 8, 1997 9.4. Support of Proprietary Virtual Interface by ifTable Specific interpretations of ifTable for the proprietary virtual, internal interface associated with an AAL5 entity in an ATM switch are as follows. Expires 7/8/97 [Page 20] draft ATM Management Objects January 8, 1997 Object Use for proprietary virtual, internal interface associated with AAL entities ====== =============================================== ifIndex Each proprietary virtual, internal interface associated with AAL entities is represented by an ifEntry. ifDescr Description of the proprietary virtual, internal interface associated with AAL entities. ifType The value that is allocated for proprietary virtual, internal interface is 53. ifSpeed See [5]. Set to 0 if the speed is not known. ifPhysAddress See [5]. An octet string of zero length if no address is used for this interface. ifAdminStatus See [5]. ifOperStatus See [5]. ifLastChange See [5]. ifName Textual name (unique on this system) of the interface or an octet string of zero length. ifHighSpeed See [5]. Set to 0 if the speed is not known. ifConnectorPresent Set to false (2). ifLinkUpDownTrapEnable Default is disabled (2). ifAlias The non-volatile 'alias' name for the interface as specified by a network manager. 9.5. AAL5 Connection Performance Statistics Group An AAL5 connection table is used to provide AAL5 performance information for each AAL5 virtual connection that is terminated at the AAL5 entity contained within an ATM switch or host. Expires 7/8/97 [Page 21] draft ATM Management Objects January 8, 1997 10. ILMI MIB and the ATM Managed Objects The ILMI MIB is specified by the ATM Forum in UNI specification [9], to manage local ATM UNIs. The support of the ATM management functions by the ILMI MIB and those contained in this memo are compared in Table 1. In this table, "yes" in the "ILMI MIB" column indicates that the management functions are supported by the ILMI MIB. The MIB groups in the "This memo" column are the groups listed in Section 7.2. For that subset of management information which the ILMI MIB and this memo have in common, every effort has been made to retain identical semantics and syntax, even though the MIB objects are identified using different OBJECT IDENTIFIERs. Expires 7/8/97 [Page 22] draft ATM Management Objects January 8, 1997 Table 1 - Structuring of ATM Managed Objects ______________________________________________________________ | |This |ILMI| ATM Mgmt.Inf. |ATM Managed Objects |memo |MIB | ______________|_________________________________|_______|____| Local Interface Information: _____________________________________________________________ ATM interface:| (1) port identifier |ATM MIB| | physical layer| (2) physical transmission types | gr.1*|yes*| configuration | (3) operational status |MIB II | | | (4) administrative status | | | | (5) last change status | | | _____________________________________________________________ ATM interface:| (1) active VPI/VCI fields |ATM MIB| | cell layer | (2) maximum number of VPCs/VCCs | gr.1 |yes | configuration | (3) configured VPCs/VCCs | | ** | | (4) ILMI VPI/VCI values | | | | (5) ATM address type | | | | (6) ATM administrative address | | | _____________________________________________________________ ATM interface:|(1) received/transmitted cells | | | cell layer |(2) cells with HEC error |MIB II |yes | performance |(3) cell header validation errors| | | _____________________________________________________________ ATM interface:|(1)DS3 PLCP severely errored |ATM MIB| | PLCP & TC | framing seconds | gr.2,3| | layer |(2)DS3 PLCP unavailable seconds | |no | performance |(3)DS3 PLCP alarm state | | | |(4)out of cell delineation events| | | |(5)TC alarm state | | | _____________________________________________________________ VP/VC link: |(1)VPI or VPI/VCI value |ATM MIB| | configuration |(2)VCL or VPL operational status | gr. 4|yes | |(3)VCL/VPL administrative status | |*** | |(4)VCL/VPL last change status | | | |(5)transmit/receive traffic/ | | | | service category parameters | | | |(6)AAL type | | | |(7)transmit/receive AAL5 SDU size| | | |(8)AAL5 encapsulation type | | | _____________________________________________________________ Expires 7/8/97 [Page 23] draft ATM Management Objects January 8, 1997 _____________________________________________________________ VP/VC |(1)cross-connect identifier | | | Cross-connect:|(2)port identifier of one | | | configuration | end | | | |(3)port identifier of the other |ATM MIB| | | end | gr. 5|no | |(4)VPI or VPI/VCI value | | | | of one end | | | |(5)VPI or VPI/VCI value of | | | | the other end | | | |(6)VC/VP cross-connect | | | | operational status | | | |(7)VC/VP cross-connect | | | | administrative status | | | |(8)VC/VP last change status | | | _____________________________________________________________ VCC AAL5 CPCS |(1)PDUs discarded for CRC errors |ATM MIB| | layer: |(2)PDUs discarded due to | gr.6 | | performance | reassembly time out | |no | |(3)PDUs discarded due to large | | | | SDUs | | | _____________________________________________________________ AAL5 entity: |(1)received/transmitted PDUs | | | |(2)PDUs discarded due to | | | | protocol errors |MIB II |no | |(3)a set of configuration/state | | | | parameters | | | _____________________________________________________________ *The operational, administrative, and last change status of the ATM interface and the physical transmission type shall be supported by the interface table in MIB II [2][5]. ILMI does not contain the administrative and last change status of the ATM interface. ** The ILMI MIB does not contain information on the ATM address type and the ATM administrative address assigned at the ATM interface. ***The ILMI MIB contains local and end-to-end operational status of the VPC/VCC segment. However, it does not contain the VPC/VCC administrative and last change status and the VCC AAL information. Expires 7/8/97 [Page 24] draft ATM Management Objects January 8, 1997 11. Definitions ATM-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, experimental, Counter32, Integer32, IpAddress, mib-2 FROM SNMPv2-SMI DisplayString, RowStatus FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF InterfaceIndex, ifIndex FROM IF-MIB AtmAddr, AtmConnKind, AtmConnCastType, AtmServiceCategory, AtmTrafficDescrParamIndex, AtmVpIdentifier, AtmVcIdentifier, AtmVorXAdminStatus, AtmVorXLastChange, AtmVorXOperStatus, atmNoTrafficDescriptor FROM ATM-TC-MIB; atmMIB MODULE-IDENTITY LAST-UPDATED "9701081122Z" ORGANIZATION "IETF AToM MIB Working Group" CONTACT-INFO " Kaj Tesink Postal: Bellcore 331 Newman Springs Road Red Bank, NJ 07701 Tel: 908-758-5254 Fax: 908-758-4177 E-mail: kaj@cc.bellcore.com" DESCRIPTION "This is the MIB Module for ATM and AAL5-related objects for managing ATM interfaces, ATM virtual links, ATM cross-connects, AAL5 entities, and and AAL5 connections." REVISION "9406072245Z" DESCRIPTION "RFC1695" ::= { experimental 41 } -- **************************************** -- * Note to RFC editor * Expires 7/8/97 [Page 25] draft ATM Management Objects January 8, 1997 -- * Replace {experimental 41} with * -- * { mib-2 37 } when publishing this * -- * MIB as RFC * -- **************************************** atmMIBObjects OBJECT IDENTIFIER ::= {atmMIB 1} -- {atmMIBObjects 1} has been moved to a separate -- specification [8]. Expires 7/8/97 [Page 26] draft ATM Management Objects January 8, 1997 -- This ATM MIB Module consists of the following groups: -- (1) ATM Interface configuration group -- (2) ATM Interface DS3 PLCP group -- (3) ATM Interface TC Sublayer group -- (4) ATM Interface VPL configuration group -- (5) ATM Interface VCL configuration group -- (6) ATM VP Cross Connect group (for PVCs) -- (7) ATM VC Cross Connect group (for PVCs) -- (8) ATM Interface AAL5 VCC performance statistics -- group Expires 7/8/97 [Page 27] draft ATM Management Objects January 8, 1997 -- ATM Interface Configuration Parameters Group -- This group contains ATM specific -- configuration information associated with -- an ATM interface beyond those -- supported using the ifTable. atmInterfaceConfTable OBJECT-TYPE SYNTAX SEQUENCE OF AtmInterfaceConfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains ATM local interface configuration parameters, one entry per ATM interface port." ::= { atmMIBObjects 2 } atmInterfaceConfEntry OBJECT-TYPE SYNTAX AtmInterfaceConfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This list contains ATM interface configuration parameters and state variables and is indexed by ifIndex values of ATM interfaces." INDEX { ifIndex } ::= { atmInterfaceConfTable 1} AtmInterfaceConfEntry ::= SEQUENCE { atmInterfaceMaxVpcs INTEGER, atmInterfaceMaxVccs INTEGER, atmInterfaceConfVpcs INTEGER, atmInterfaceConfVccs INTEGER, atmInterfaceMaxActiveVpiBits INTEGER, atmInterfaceMaxActiveVciBits INTEGER, atmInterfaceIlmiVpi AtmVpIdentifier, atmInterfaceIlmiVci AtmVcIdentifier, atmInterfaceAddressType INTEGER, atmInterfaceAdminAddr AtmAddr, atmInterfaceMyNeighborIpAddress IpAddress, atmInterfaceMyNeighborIfName DisplayString, atmInterfaceCurrentMaxVpiBits INTEGER, Expires 7/8/97 [Page 28] draft ATM Management Objects January 8, 1997 atmInterfaceCurrentMaxVciBits INTEGER, atmInterfaceSubscrAddress AtmAddr } atmInterfaceMaxVpcs OBJECT-TYPE SYNTAX INTEGER (0..4096) MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum number of VPCs (PVPCs and SVPCs) supported at this ATM interface. At the ATM UNI, the maximum number of VPCs (PVPCs and SVPCs) ranges from 0 to 256 only." ::= { atmInterfaceConfEntry 1} atmInterfaceMaxVccs OBJECT-TYPE SYNTAX INTEGER (0..65536) MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum number of VCCs (PVCCs and SVCCs) supported at this ATM interface." ::= { atmInterfaceConfEntry 2} atmInterfaceConfVpcs OBJECT-TYPE SYNTAX INTEGER (0..4096) MAX-ACCESS read-only STATUS current DESCRIPTION "The number of VPCs (PVPC, Soft PVPC and SVPC) currently in use at this ATM interface. It includes the number of PVPCs and Soft PVPCs that are configured at the interface, plus the number of SVPCs that are currently established at the interface. At the ATM UNI, the configured number of VPCs (PVPCs and SVPCs) can range from 0 to 256 only." ::= { atmInterfaceConfEntry 3} atmInterfaceConfVccs OBJECT-TYPE SYNTAX INTEGER (0..65536) MAX-ACCESS read-only Expires 7/8/97 [Page 29] draft ATM Management Objects January 8, 1997 STATUS current DESCRIPTION "The number of VCCs (PVCC, Soft PVCC and SVCC) currently in use at this ATM interface. It includes the number of PVCCs and Soft PVCCs that are configured at the interface, plus the number of SVCCs that are currently established at the interface." ::= { atmInterfaceConfEntry 4} atmInterfaceMaxActiveVpiBits OBJECT-TYPE SYNTAX INTEGER (0..12) MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum number of active VPI bits configured for use at the ATM interface. At the ATM UNI, the maximum number of active VPI bits configured for use ranges from 0 to 8 only." ::= { atmInterfaceConfEntry 5} atmInterfaceMaxActiveVciBits OBJECT-TYPE SYNTAX INTEGER (0..16) MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum number of active VCI bits configured for use at this ATM interface." ::= { atmInterfaceConfEntry 6} atmInterfaceIlmiVpi OBJECT-TYPE SYNTAX AtmVpIdentifier MAX-ACCESS read-write STATUS current DESCRIPTION "The VPI value of the VCC supporting the ILMI at this ATM interface. If the values of atmInterfaceIlmiVpi and atmInterfaceIlmiVci are both equal to zero then the ILMI is not supported at this ATM interface." DEFVAL { 0 } ::= { atmInterfaceConfEntry 7} atmInterfaceIlmiVci OBJECT-TYPE Expires 7/8/97 [Page 30] draft ATM Management Objects January 8, 1997 SYNTAX AtmVcIdentifier MAX-ACCESS read-write STATUS current DESCRIPTION "The VCI value of the VCC supporting the ILMI at this ATM interface. If the values of atmInterfaceIlmiVpi and atmInterfaceIlmiVci are both equal to zero then the ILMI is not supported at this ATM interface." DEFVAL { 16 } ::= { atmInterfaceConfEntry 8} 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 } atmInterfaceAdminAddr OBJECT-TYPE SYNTAX AtmAddr MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The primary address assigned for administrative purposes, for example, an address associated with the service provider side of a public network UNI (thus, the value of this address corresponds with the value of ifPhysAddress at the host side). If this interface has no assigned administrative address, or when the address used for administrative purposes is the same as that used for ifPhysAddress, then this is an octet string of zero length." ::= { atmInterfaceConfEntry 10 } atmInterfaceMyNeighborIpAddress OBJECT-TYPE SYNTAX IpAddress Expires 7/8/97 [Page 31] draft ATM Management Objects January 8, 1997 MAX-ACCESS read-write STATUS current DESCRIPTION "The IP address of the neighbor system connected to the far end of this interface, to which a Network Management Station can send SNMP messages, as IP datagrams sent to UDP port 161, in order to access network management information concerning the operation of that system. Note that the value of this object may be obtained in different ways, e.g., by manual configuration, or through ILMI interaction with the neighbor system." ::= { atmInterfaceConfEntry 11 } atmInterfaceMyNeighborIfName OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-write STATUS current DESCRIPTION "The textual name of the interface on the neighbor system on the far end of this interface, and to which this interface connects. If the neighbor system is manageable through SNMP and supports the object ifName, the value of this object must be identical with that of ifName for the ifEntry of the lowest level physical interface for this port. If this interface does not have a textual name, the value of this object is a zero length string. Note that the value of this object may be obtained in different ways, e.g., by manual configuration, or through ILMI interaction with the neighbor system." ::= { atmInterfaceConfEntry 12 } atmInterfaceCurrentMaxVpiBits OBJECT-TYPE SYNTAX INTEGER (0..12) MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum number of VPI Bits that may currently be used at this ATM interface. The value is the minimum of atmInterfaceMaxActiveVpiBits, and the atmInterfaceMaxActiveVpiBits of the interface's UNI/NNI peer. Expires 7/8/97 [Page 32] draft ATM Management Objects January 8, 1997 If the interface does not negotiate with its peer to determine the number of VPI Bits that can be used on the interface, then the value of this object must equal atmInterfaceMaxActiveVpiBits." ::= { atmInterfaceConfEntry 13 } atmInterfaceCurrentMaxVciBits OBJECT-TYPE SYNTAX INTEGER (0..16) MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum number of VCI Bits that may currently be used at this ATM interface. The value is the minimum of atmInterfaceMaxActiveVciBits, and the atmInterfaceMaxActiveVpiBits of the interface's UNI/NNI peer. If the interface does not negotiate with its peer to determine the number of VCI Bits that can be used on the interface, then the value of this object must equal atmInterfaceMaxActiveVciBits." ::= { atmInterfaceConfEntry 14 } atmInterfaceSubscrAddress OBJECT-TYPE SYNTAX AtmAddr MAX-ACCESS read-write STATUS current DESCRIPTION "The identifier assigned by a service provider to the network side of a public network UNI. If this interface has no assigned service provider address, or for other interfaces this is an octet string of zero length." ::= { atmInterfaceConfEntry 15 } Expires 7/8/97 [Page 33] draft ATM Management Objects January 8, 1997 -- The ATM Interface DS3 PLCP Group -- This group contains the DS3 PLCP configuration and -- state parameters of those ATM interfaces -- which use DS3 PLCP for carrying ATM cells over DS3. atmInterfaceDs3PlcpTable OBJECT-TYPE SYNTAX SEQUENCE OF AtmInterfaceDs3PlcpEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains ATM interface DS3 PLCP parameters and state variables, one entry per ATM interface port." ::= { atmMIBObjects 3} atmInterfaceDs3PlcpEntry OBJECT-TYPE SYNTAX AtmInterfaceDs3PlcpEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This list contains DS3 PLCP parameters and state variables at the ATM interface and is indexed by the ifIndex value of the ATM interface." INDEX { ifIndex } ::= { atmInterfaceDs3PlcpTable 1} AtmInterfaceDs3PlcpEntry ::= SEQUENCE { atmInterfaceDs3PlcpSEFSs Counter32, atmInterfaceDs3PlcpAlarmState INTEGER, atmInterfaceDs3PlcpUASs Counter32 } atmInterfaceDs3PlcpSEFSs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of DS3 PLCP Severely Errored Framing Second (SEFS). Each SEFS represents a one-second interval which contains one or more SEF event." ::= { atmInterfaceDs3PlcpEntry 1} Expires 7/8/97 [Page 34] draft ATM Management Objects January 8, 1997 atmInterfaceDs3PlcpAlarmState OBJECT-TYPE SYNTAX INTEGER { noAlarm(1), receivedFarEndAlarm(2), incomingLOF(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "This variable indicates if there is an alarm present for the DS3 PLCP. The value receivedFarEndAlarm means that the DS3 PLCP has received an incoming Yellow Signal, the value incomingLOF means that the DS3 PLCP has declared a loss of frame (LOF) failure condition, and the value noAlarm means that there are no alarms present. Transition from the failure to the no alarm state occurs when no defects (e.g., LOF) are received for more than 10 seconds." ::= { atmInterfaceDs3PlcpEntry 2} atmInterfaceDs3PlcpUASs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The counter associated with the number of Unavailable Seconds encountered by the PLCP." ::= { atmInterfaceDs3PlcpEntry 3} Expires 7/8/97 [Page 35] draft ATM Management Objects January 8, 1997 -- The ATM Interface TC Sublayer Group -- This group contains TC sublayer configuration and -- state parameters of those ATM interfaces -- which use TC sublayer for carrying ATM cells over -- SONET/SDH or DS3. atmInterfaceTCTable OBJECT-TYPE SYNTAX SEQUENCE OF AtmInterfaceTCEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains ATM interface TC Sublayer parameters and state variables, one entry per ATM interface port." ::= { atmMIBObjects 4} atmInterfaceTCEntry OBJECT-TYPE SYNTAX AtmInterfaceTCEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This list contains TC Sublayer parameters and state variables at the ATM interface and is indexed by the ifIndex value of the ATM interface." INDEX {ifIndex } ::= { atmInterfaceTCTable 1} AtmInterfaceTCEntry ::= SEQUENCE { atmInterfaceOCDEvents Counter32, atmInterfaceTCAlarmState INTEGER } atmInterfaceOCDEvents OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the Out of Cell Delineation (OCD) events occur. If seven consecutive ATM cells have Header Error Control (HEC) violations, an OCD event occurs. A high number of OCD events may indicate a problem with the TC Sublayer." Expires 7/8/97 [Page 36] draft ATM Management Objects January 8, 1997 ::= { atmInterfaceTCEntry 1} atmInterfaceTCAlarmState OBJECT-TYPE SYNTAX INTEGER { noAlarm(1), lcdFailure(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "This variable indicates if there is an alarm present for the TC Sublayer. The value lcdFailure(2) indicates that the TC Sublayer is currently in the Loss of Cell Delineation (LCD) defect maintenance state. The value noAlarm(1) indicates that the TC Sublayer is currently not in the LCD defect maintenance state." ::= { atmInterfaceTCEntry 2} Expires 7/8/97 [Page 37] draft ATM Management Objects January 8, 1997 -- ATM Traffic Descriptor Parameter Group -- This group contains a set of self-consistent -- ATM traffic parameters including the -- ATM traffic service category. -- The ATM virtual link tables (i.e., VPL and VCL tables) -- will use this ATM Traffic Descriptor table -- to assign traffic parameters and service category -- to the receive and transmit directions of -- the ATM virtual links (i.e., VPLs and VCLs). -- The ATM VPL or VCL table will indicate a row -- in the atmTrafficDescrParamTable -- using its atmTrafficDescrParamIndex value. -- The management application can then compare a set of -- ATM traffic parameters with a single value. -- If no suitable row(s) in the atmTrafficDescrParamTable -- exists, the manager must create a new row(s) in this -- table. If such a row is created, agent checks the -- sanity of that set of ATM traffic parameter values. -- The manager may use atmTrafficDescrParamIndexNext -- in order to obtain a free atmTrafficDescrParamIndex -- value. -- When creating a new row, the parameter values -- will be checked for self-consistency. -- Predefined/template rows may be supported. -- A row in the atmTrafficDescrParamTable is deleted -- by setting the atmTrafficDescrRowStatus to destroy(6). -- The agent will check whether this row is still in use -- by any entry of the atmVplTable or atmVclTable. -- The agent denies the request if the row is still in -- use. -- The ATM Traffic Descriptor Parameter Table atmTrafficDescrParamTable OBJECT-TYPE SYNTAX SEQUENCE OF AtmTrafficDescrParamEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION Expires 7/8/97 [Page 38] draft ATM Management Objects January 8, 1997 "This table contains information on ATM traffic descriptor type and the associated parameters." ::= { atmMIBObjects 5} atmTrafficDescrParamEntry OBJECT-TYPE SYNTAX AtmTrafficDescrParamEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This list contains ATM traffic descriptor type and the associated parameters." INDEX {atmTrafficDescrParamIndex} ::= { atmTrafficDescrParamTable 1} AtmTrafficDescrParamEntry ::= SEQUENCE { atmTrafficDescrParamIndex AtmTrafficDescrParamIndex, atmTrafficDescrType OBJECT IDENTIFIER, atmTrafficDescrParam1 Integer32, atmTrafficDescrParam2 Integer32, atmTrafficDescrParam3 Integer32, atmTrafficDescrParam4 Integer32, atmTrafficDescrParam5 Integer32, atmTrafficQoSClass INTEGER, atmTrafficDescrRowStatus RowStatus, atmServiceCategory AtmServiceCategory } atmTrafficDescrParamIndex OBJECT-TYPE SYNTAX AtmTrafficDescrParamIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object is used by the virtual link table (i.e., VPL or VCL table) to identify the row of this table. When creating a new row in the table the value of this index may be obtained by retrieving the value of atmTrafficDescrParamIndexNext." ::= { atmTrafficDescrParamEntry 1} atmTrafficDescrType OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-create STATUS current Expires 7/8/97 [Page 39] draft ATM Management Objects January 8, 1997 DESCRIPTION "The value of this object identifies the type of ATM traffic descriptor. The type may indicate no traffic descriptor or traffic descriptor with one or more parameters. These parameters are specified as a parameter vector, in the corresponding instances of the objects: atmTrafficDescrParam1 atmTrafficDescrParam2 atmTrafficDescrParam3 atmTrafficDescrParam4 atmTrafficDescrParam5." DEFVAL { atmNoTrafficDescriptor } ::= { atmTrafficDescrParamEntry 2} atmTrafficDescrParam1 OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-create STATUS current DESCRIPTION "The first parameter of the ATM traffic descriptor used according to the value of atmTrafficDescrType." DEFVAL { 0 } ::= { atmTrafficDescrParamEntry 3} atmTrafficDescrParam2 OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-create STATUS current DESCRIPTION "The second parameter of the ATM traffic descriptor used according to the value of atmTrafficDescrType." DEFVAL { 0 } ::= { atmTrafficDescrParamEntry 4} atmTrafficDescrParam3 OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-create STATUS current DESCRIPTION "The third parameter of the ATM traffic descriptor used according to the value of Expires 7/8/97 [Page 40] draft ATM Management Objects January 8, 1997 atmTrafficDescrType." DEFVAL { 0 } ::= { atmTrafficDescrParamEntry 5} atmTrafficDescrParam4 OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-create STATUS current DESCRIPTION "The fourth parameter of the ATM traffic descriptor used according to the value of atmTrafficDescrType." DEFVAL { 0 } ::= { atmTrafficDescrParamEntry 6} atmTrafficDescrParam5 OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-create STATUS current DESCRIPTION "The fifth parameter of the ATM traffic descriptor used according to the value of atmTrafficDescrType." DEFVAL { 0 } ::= { atmTrafficDescrParamEntry 7} atmTrafficQoSClass OBJECT-TYPE SYNTAX INTEGER (0..255) MAX-ACCESS read-create STATUS deprecated DESCRIPTION "The value of this object identifies the QoS Class. Four Service classes have been specified in the ATM Forum UNI Specification: Service Class A: Constant bit rate video and Circuit emulation Service Class B: Variable bit rate video/audio Service Class C: Connection-oriented data Service Class D: Connectionless data Four QoS classes numbered 1, 2, 3, and 4 have been specified with the aim to support service classes A, B, C, and D respectively. An unspecified QoS Class numbered `0' is used for best effort traffic." DEFVAL { 0 } Expires 7/8/97 [Page 41] draft ATM Management Objects January 8, 1997 ::= { atmTrafficDescrParamEntry 8} atmTrafficDescrRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object is used to create a new row or modify or delete an existing row in this table." DEFVAL { active } ::= {atmTrafficDescrParamEntry 9} atmServiceCategory OBJECT-TYPE SYNTAX AtmServiceCategory MAX-ACCESS read-create STATUS current DESCRIPTION " The ATM service category." DEFVAL { ubr } ::= { atmTrafficDescrParamEntry 10} Expires 7/8/97 [Page 42] draft ATM Management Objects January 8, 1997 -- ATM Interface Virtual Path Link (VPL) Group -- This group contains configuration and state -- information of a bi-directional Virtual Path Link -- (VPL) -- This table can be used to create, delete or modify -- a VPL that is terminated in an ATM host or switch. -- This table can also be used to create, delete or -- modify a VPL which is cross-connected to another -- VPL. -- In the example below, the traffic flows on the receive -- and transmit directions of the VPLs are characterized -- by atmVplReceiveTrafficDescrIndex and -- atmVplTransmitTrafficDescrIndex respectively. -- The cross-connected VPLs are identified by -- atmVplCrossConnectIdentifier. -- ________________________________ -- | | -- VPL | ATM Host, Switch, or Network | VPL -- receive | | receive -- ========> X X <======= -- <======== X X ========> -- transmit | | transmit -- |______________________________| -- The ATM Interface VPL Table atmVplTable OBJECT-TYPE SYNTAX SEQUENCE OF AtmVplEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The Virtual Path Link (VPL) table. A bi-directional VPL is modeled as one entry in this table." ::= { atmMIBObjects 6} Expires 7/8/97 [Page 43] draft ATM Management Objects January 8, 1997 atmVplEntry OBJECT-TYPE SYNTAX AtmVplEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the VPL table. This entry is used to model a bi-directional VPL. To create a VPL at an ATM interface, either of the following procedures are used: Negotiated VPL establishment (1) The management application creates a VPL entry in the atmVplTable by setting atmVplRowStatus to createAndWait(5). This may fail for the following reasons: - The selected VPI value is unavailable, - The selected VPI value is in use. Otherwise, the agent creates a row and reserves the VPI value on that port. (2) The manager selects an existing row(s) in the atmTrafficDescrParamTable, thereby, selecting a set of self-consistent ATM traffic parameters and the service category for receive and transmit directions of the VPL. (2a) If no suitable row(s) in the atmTrafficDescrParamTable exists, the manager must create a new row(s) in that table. (2b) The manager characterizes the VPL's traffic parameters through setting the atmVplReceiveTrafficDescrIndex and the atmVplTransmitTrafficDescrIndex values in the VPL table, which point to the rows containing desired ATM traffic parameter values in the atmTrafficDescrParamTable. The agent will check the availability of resources and may refuse the request. If the transmit and receive service categories are inconsistent, the agent should refuse the request. Expires 7/8/97 [Page 44] draft ATM Management Objects January 8, 1997 (3) The manager activates the VPL by setting the the atmVplRowStatus to active(1). If this set is successful, the agent has reserved the resources to satisfy the requested traffic parameter values and the service category for that VPL. (4) If the VPL terminates a VPC in the ATM host or switch, the manager turns on the atmVplAdminStatus to up(1) to turn the VPL traffic flow on. Otherwise, the atmVpCrossConnectTable must be used to cross-connect the VPL to another VPL(s) in an ATM switch or network. One-Shot VPL Establishment A VPL may also be established in one step by a set-request with all necessary VPL parameter values and atmVplRowStatus set to createAndGo(4). In contrast to the negotiated VPL establishment which allows for detailed error checking (i.e., set errors are explicitly linked to particular resource acquisition failures), the one-shot VPL establishment performs the setup on one operation but does not have the advantage of step-wise error checking. VPL Retirement A VPL is released by setting atmVplRowStatus to destroy(6), and the agent may release all associated resources." INDEX {ifIndex, atmVplVpi } ::= { atmVplTable 1} AtmVplEntry ::= SEQUENCE { atmVplVpi AtmVpIdentifier, atmVplAdminStatus AtmVorXAdminStatus, atmVplOperStatus AtmVorXOperStatus, atmVplLastChange AtmVorXLastChange, atmVplReceiveTrafficDescrIndex AtmTrafficDescrParamIndex, Expires 7/8/97 [Page 45] draft ATM Management Objects January 8, 1997 atmVplTransmitTrafficDescrIndex AtmTrafficDescrParamIndex, atmVplCrossConnectIdentifier INTEGER, atmVplRowStatus RowStatus, atmVplCastType AtmConnCastType, atmVplConnKind AtmConnKind } atmVplVpi OBJECT-TYPE SYNTAX AtmVpIdentifier MAX-ACCESS not-accessible STATUS current DESCRIPTION "The VPI value of the VPL." ::= { atmVplEntry 1} atmVplAdminStatus OBJECT-TYPE SYNTAX AtmVorXAdminStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object is implemented only for a VPL which terminates a VPC (i.e., one which is NOT cross-connected to other VPLs). Its value specifies the desired administrative state of the VPL." DEFVAL { down } ::= { atmVplEntry 2} atmVplOperStatus OBJECT-TYPE SYNTAX AtmVorXOperStatus MAX-ACCESS read-only STATUS current DESCRIPTION "The current operational status of the VPL." ::= { atmVplEntry 3} atmVplLastChange OBJECT-TYPE SYNTAX AtmVorXLastChange MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the time this VPL entered its current operational state." Expires 7/8/97 [Page 46] draft ATM Management Objects January 8, 1997 ::= { atmVplEntry 4 } atmVplReceiveTrafficDescrIndex OBJECT-TYPE SYNTAX AtmTrafficDescrParamIndex MAX-ACCESS read-create STATUS current DESCRIPTION "The value of this object identifies the row in the atmTrafficDescrParamTable which applies to the receive direction of the VPL." DEFVAL { 0 } ::= { atmVplEntry 5} atmVplTransmitTrafficDescrIndex OBJECT-TYPE SYNTAX AtmTrafficDescrParamIndex MAX-ACCESS read-create STATUS current DESCRIPTION "The value of this object identifies the row in the atmTrafficDescrParamTable which applies to the transmit direction of the VPL." DEFVAL { 0 } ::= { atmVplEntry 6} atmVplCrossConnectIdentifier OBJECT-TYPE SYNTAX INTEGER (0..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "This object is implemented only for a VPL which is cross-connected to other VPLs that belong to the same VPC. All such associated VPLs have the same value of this object, and all their cross-connections are identified by entries in the atmVpCrossConnectTable for which atmVpCrossConnectIndex has the same value. The value of this object is initialized by the agent after the associated entries in the atmVpCrossConnectTable have been created." ::= {atmVplEntry 7} atmVplRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create Expires 7/8/97 [Page 47] draft ATM Management Objects January 8, 1997 STATUS current DESCRIPTION "This object is used to create, delete or modify a row in this table. To create a new VCL, this object is initially set to 'createAndWait' or 'createAndGo'. This object should not be set to 'active' unless the following columnar objects have been set to their desired value in this row: atmVplReceiveTrafficDescrIndex and atmVplTransmitTrafficDescrIndex." DEFVAL { active } ::= {atmVplEntry 8} atmVplCastType OBJECT-TYPE SYNTAX AtmConnCastType MAX-ACCESS read-create STATUS current DESCRIPTION "The connection topology type." DEFVAL { p2p } ::= {atmVplEntry 9} atmVplConnKind OBJECT-TYPE SYNTAX AtmConnKind MAX-ACCESS read-create STATUS current DESCRIPTION "The use of call control." DEFVAL { pvc } ::= {atmVplEntry 10} Expires 7/8/97 [Page 48] draft ATM Management Objects January 8, 1997 -- ATM Interface Virtual Channel Link (VCL) Group -- This group contains configuration and state -- information of a bi-directional Virtual Channel -- Link (VCL) at an ATM interface. -- This table can be used to create, delete or modify -- a VCL that is terminated in an ATM host or switch. -- This table can also be -- used to create, delete or modify a VCL that is -- cross-connected to another VCL. -- The ATM Interface VCL Table atmVclTable OBJECT-TYPE SYNTAX SEQUENCE OF AtmVclEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The Virtual Channel Link (VCL) table. A bi-directional VCL is modeled as one entry in this table." ::= { atmMIBObjects 7} atmVclEntry OBJECT-TYPE SYNTAX AtmVclEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the VCL table. This entry is used to model a bi-directional VCL. To create a VCL at an ATM interface, either of the following procedures are used: Negotiated VCL establishment (1) The management application creates a VCL entry in the atmVclTable by setting atmVclRowStatus to createAndWait(5). This may fail for the following reasons: - The selected VPI/VCI values are unavailable, - The selected VPI/VCI values are in use. Otherwise, the agent creates a row and Expires 7/8/97 [Page 49] draft ATM Management Objects January 8, 1997 reserves the VPI/VCI values on that port. (2) The manager selects an existing row(s) in the atmTrafficDescrParamTable, thereby, selecting a set of self-consistent ATM traffic parameters and the service category for receive and transmit directions of the VCL. (2a) If no suitable row(s) in the atmTrafficDescrParamTable exists, the manager must create a new row(s) in that table. (2b) The manager characterizes the VCL's traffic parameters through setting the atmVclReceiveTrafficDescrIndex and the atmVclTransmitTrafficDescrIndex values in the VCL table, which point to the rows containing desired ATM traffic parameter values in the atmTrafficDescrParamTable. The agent will check the availability of resources and may refuse the request. If the transmit and receive service categories are inconsistent, the agent should refuse the request. (3) The manager activates the VCL by setting the the atmVclRowStatus to active(1) (for requirements on this activation see the description of atmVclRowStatus). If this set is successful, the agent has reserved the resources to satisfy the requested traffic parameter values and the service category for that VCL. (4) If the VCL terminates a VCC in the ATM host or switch, the manager turns on the atmVclAdminStatus to up(1) to turn the VCL traffic flow on. Otherwise, the atmVcCrossConnectTable must be used to cross-connect the VCL to another VCL(s) in an ATM switch or network. One-Shot VCL Establishment A VCL may also be established in one step by a Expires 7/8/97 [Page 50] draft ATM Management Objects January 8, 1997 set-request with all necessary VCL parameter values and atmVclRowStatus set to createAndGo(4). In contrast to the negotiated VCL establishment which allows for detailed error checking (i.e., set errors are explicitly linked to particular resource acquisition failures), the one-shot VCL establishment performs the setup on one operation but does not have the advantage of step-wise error checking. VCL Retirement A VCL is released by setting atmVclRowStatus to destroy(6), and the agent may release all associated resources." INDEX {ifIndex, atmVclVpi, atmVclVci } ::= { atmVclTable 1} AtmVclEntry ::= SEQUENCE { atmVclVpi AtmVpIdentifier, atmVclVci AtmVcIdentifier, atmVclAdminStatus AtmVorXAdminStatus, atmVclOperStatus AtmVorXOperStatus, atmVclLastChange AtmVorXLastChange, atmVclReceiveTrafficDescrIndex AtmTrafficDescrParamIndex, atmVclTransmitTrafficDescrIndex AtmTrafficDescrParamIndex, atmVccAalType INTEGER, atmVccAal5CpcsTransmitSduSize INTEGER, atmVccAal5CpcsReceiveSduSize INTEGER, atmVccAal5EncapsType INTEGER, atmVclCrossConnectIdentifier INTEGER, atmVclRowStatus RowStatus, atmVclCastType AtmConnCastType, atmVclConnKind AtmConnKind } atmVclVpi OBJECT-TYPE SYNTAX AtmVpIdentifier MAX-ACCESS not-accessible STATUS current DESCRIPTION Expires 7/8/97 [Page 51] draft ATM Management Objects January 8, 1997 "The VPI value of the VCL." ::= { atmVclEntry 1} atmVclVci OBJECT-TYPE SYNTAX AtmVcIdentifier MAX-ACCESS not-accessible STATUS current DESCRIPTION "The VCI value of the VCL." ::= { atmVclEntry 2} atmVclAdminStatus OBJECT-TYPE SYNTAX AtmVorXAdminStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object is implemented only for a VCL which terminates a VCC (i.e., one which is NOT cross-connected to other VCLs). Its value specifies the desired administrative state of the VCL." DEFVAL { down } ::= { atmVclEntry 3} atmVclOperStatus OBJECT-TYPE SYNTAX AtmVorXOperStatus MAX-ACCESS read-only STATUS current DESCRIPTION "The current operational status of the VCL." ::= { atmVclEntry 4} atmVclLastChange OBJECT-TYPE SYNTAX AtmVorXLastChange MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the time this VCL entered its current operational state." ::= { atmVclEntry 5 } atmVclReceiveTrafficDescrIndex OBJECT-TYPE SYNTAX AtmTrafficDescrParamIndex MAX-ACCESS read-create STATUS current Expires 7/8/97 [Page 52] draft ATM Management Objects January 8, 1997 DESCRIPTION "The value of this object identifies the row in the ATM Traffic Descriptor Table which applies to the receive direction of this VCL." DEFVAL { 0 } ::= { atmVclEntry 6} atmVclTransmitTrafficDescrIndex OBJECT-TYPE SYNTAX AtmTrafficDescrParamIndex MAX-ACCESS read-create STATUS current DESCRIPTION "The value of this object identifies the row of the ATM Traffic Descriptor Table which applies to the transmit direction of this VCL." DEFVAL { 0 } ::= { atmVclEntry 7} atmVccAalType OBJECT-TYPE SYNTAX INTEGER { aal1(1), aal34(2), aal5(3), other(4), unknown(5) } MAX-ACCESS read-create STATUS current DESCRIPTION "An instance of this object only exists when the local VCL end-point is also the VCC end-point, and AAL is in use. The type of AAL used on this VCC. The AAL type includes AAL1, AAL3/4, and AAL5. The other(4) may be user-defined AAL type. The unknown type indicates that the AAL type cannot be determined." DEFVAL { aal5 } ::= { atmVclEntry 8 } atmVccAal5CpcsTransmitSduSize OBJECT-TYPE SYNTAX INTEGER (1..65535) MAX-ACCESS read-create STATUS current DESCRIPTION Expires 7/8/97 [Page 53] draft ATM Management Objects January 8, 1997 "An instance of this object only exists when the local VCL end-point is also the VCC end-point, and AAL5 is in use. The maximum AAL5 CPCS SDU size in octets that is supported on the transmit direction of this VCC." DEFVAL { 9188 } ::= { atmVclEntry 9 } atmVccAal5CpcsReceiveSduSize OBJECT-TYPE SYNTAX INTEGER (1..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "An instance of this object only exists when the local VCL end-point is also the VCC end-point, and AAL5 is in use. The maximum AAL5 CPCS SDU size in octets that is supported on the receive direction of this VCC." DEFVAL { 9188 } ::= { atmVclEntry 10 } atmVccAal5EncapsType OBJECT-TYPE SYNTAX INTEGER { vcMultiplexRoutedProtocol(1), vcMultiplexBridgedProtocol8023(2), vcMultiplexBridgedProtocol8025(3), vcMultiplexBridgedProtocol8026(4), vcMultiplexLANemulation8023(5), vcMultiplexLANemulation8025(6), llcEncapsulation(7), multiprotocolFrameRelaySscs(8), other(9), unknown(10) } MAX-ACCESS read-create STATUS current DESCRIPTION "An instance of this object only exists when the local VCL end-point is also the VCC end-point, and AAL5 is in use. The type of data encapsulation used over the AAL5 SSCS layer. The definitions reference RFC 1483 Multiprotocol Encapsulation over ATM AAL5 and to the ATM Forum LAN Emulation specification." Expires 7/8/97 [Page 54] draft ATM Management Objects January 8, 1997 DEFVAL { llcEncapsulation } ::= { atmVclEntry 11 } atmVclCrossConnectIdentifier OBJECT-TYPE SYNTAX INTEGER (0..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "This object is implemented only for a VCL which is cross-connected to other VCLs that belong to the same VCC. All such associated VCLs have the same value of this object, and all their cross-connections are identified by entries in the atmVcCrossConnectTable for which atmVcCrossConnectIndex has the same value. The value of this object is initialized by the agent after the associated entries in the atmVcCrossConnectTable have been created." ::= {atmVclEntry 12} atmVclRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object is used to create, delete or modify a row in this table. To create a new VCL, this object is initially set to 'createAndWait' or 'createAndGo'. This object should not be set to 'active' unless the following columnar objects have been set to their desired value in this row: atmVclReceiveTrafficDescrIndex, atmVclTransmitTrafficDescrIndex. In addition, if the local VCL end-point is also the VCC end-point: atmVccAalType. In addition, for AAL5 connections only: atmVccAal5CpcsTransmitSduSize, atmVccAal5CpcsReceiveSduSize, and atmVccAal5EncapsType. (The existence of these objects imply the AAL connection type.)" DEFVAL { active } Expires 7/8/97 [Page 55] draft ATM Management Objects January 8, 1997 ::= {atmVclEntry 13} atmVclCastType OBJECT-TYPE SYNTAX AtmConnCastType MAX-ACCESS read-create STATUS current DESCRIPTION "The connection topology type." DEFVAL { p2p } ::= {atmVclEntry 14} atmVclConnKind OBJECT-TYPE SYNTAX AtmConnKind MAX-ACCESS read-create STATUS current DESCRIPTION "The use of call control." DEFVAL { pvc } ::= {atmVclEntry 15} Expires 7/8/97 [Page 56] draft ATM Management Objects January 8, 1997 -- ATM Virtual Path (VP) Cross Connect Group -- This group contains configuration and state -- information of point-to-point, -- point-to-multipoint, or multipoint-to-multipoint -- VP cross-connects for PVCs. -- This table has read-create access and can be used -- to cross-connect the VPLs together in an ATM switch -- or network. The atmVpCrossConnectIndex -- is used to associate the related -- VPLs that are cross-connected together. -- The ATM VP Cross Connect Group -- models each bi-directional VPC -- cross-connect as a set of entries in -- the atmVpCrossConnectTable. A -- point-to-point VPC cross-connect is modeled -- as one entry; a point-to-multipoint (N leafs) VPC -- cross-connect as N entries in this table; and -- a multipoint-to-multipoint (N parties) VPC cross- -- connect as N(N-1)/2 entries in this table. -- In the latter cases, all the N (or N(N-1)/2) entries -- are associated with a single VPC cross-connect by -- having the same value of atmVpCrossConnectIndex. -- _________________________________________ -- | | -- Low | ATM Switch or Network | High -- port| | port -- _____|>> from low to high VPC traffic flow >>|______ -- |<< from high to low VPC traffic flow <<| -- | | -- |_______________________________________| -- -- The terms low and high are chosen to represent -- numerical ordering of the two interfaces associated -- with a VPC cross-connect. That is, the ATM interface -- with the lower value of ifIndex is termed 'low', -- while the other ATM interface associated with the -- VPC cross-connect is termed 'high'. This terminology -- is used to provide directional information; for -- example, the atmVpCrossConnectL2HOperStatus applies Expires 7/8/97 [Page 57] draft ATM Management Objects January 8, 1997 -- to the low->high direction, and -- atmVpCrossConnectH2LOperStatus applies to the -- high->low direction, as illustrated above. atmVpCrossConnectIndexNext OBJECT-TYPE SYNTAX INTEGER (0..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains an appropriate value to be used for atmVpCrossConnectIndex when creating entries in the atmVpCrossConnectTable. The value 0 indicates that no unassigned entries are available. To obtain the atmVpCrossConnectIndex 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 unassigned index." ::= { atmMIBObjects 8 } -- The ATM VP Cross Connect Table atmVpCrossConnectTable OBJECT-TYPE SYNTAX SEQUENCE OF AtmVpCrossConnectEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The ATM VP Cross Connect table. A bi- directional VP cross-connect which cross-connects two VPLs is modeled as one entry in this table." ::= { atmMIBObjects 9 } atmVpCrossConnectEntry OBJECT-TYPE SYNTAX AtmVpCrossConnectEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION Expires 7/8/97 [Page 58] draft ATM Management Objects January 8, 1997 "An entry in the ATM VP Cross Connect table. This entry is used to model a bi-directional ATM VP cross-connect which cross-connects two VPLs. Step-wise Procedures to set up a VP Cross-connect Once the entries in the atmVplTable are created, the following procedures are used to cross-connect the VPLs together. (1) The manager obtains a unique atmVpCrossConnectIndex by reading the atmVpCrossConnectIndexNext object. (2) Next, the manager creates a set of one or more rows in the ATM VP Cross Connect Table, one for each cross-connection between two VPLs. Each row is indexed by the ATM interface port numbers and VPI values of the two ends of that cross-connection. This set of rows specifies the topology of the VPC cross-connect and is identified by a single value of atmVpCrossConnectIndex. Negotiated VP Cross-Connect Establishment (2a) The manager creates a row in this table by setting atmVpCrossConnectRowStatus to createAndWait(5). The agent checks the requested topology and the mutual sanity of the ATM traffic parameters and service categories, i.e., the row creation fails if: - the requested topology is incompatible with associated values of atmVplCastType, - the requested topology is not supported by the agent, - the traffic/service category parameter values associated with the requested row are incompatible with those of already existing rows for this VP cross-connect. [For example, for setting up a point-to-point VP cross-connect, the ATM traffic parameters in the receive direction Expires 7/8/97 [Page 59] draft ATM Management Objects January 8, 1997 of a VPL at the low end of the cross-connect must equal to the traffic parameters in the transmit direction of the other VPL at the high end of the cross-connect, otherwise, the row creation fails.] The agent also checks for internal errors in building the cross-connect. The atmVpCrossConnectIndex values in the corresponding atmVplTable rows are filled in by the agent at this point. (2b) The manager promotes the row in the atmVpCrossConnectTable by setting atmVpCrossConnectRowStatus to active(1). If this set is successful, the agent has reserved the resources specified by the ATM traffic parameter and Service category values for each direction of the VP cross-connect in an ATM switch or network. (3) The manager sets the atmVpCrossConnectAdminStatus to up(1) in all rows of this VP cross-connect to turn the traffic flow on. One-Shot VP Cross-Connect Establishment A VP cross-connect may also be established in one step by a set-request with all necessary parameter values and atmVpCrossConnectRowStatus set to createAndGo(4). In contrast to the negotiated VP cross-connect establishment which allows for detailed error checking (i.e., set errors are explicitly linked to particular resource acquisition failures), the one-shot VP cross-connect establishment performs the setup on one operation but does not have the advantage of step-wise error checking. VP Cross-Connect Retirement A VP cross-connect identified by a particular Expires 7/8/97 [Page 60] draft ATM Management Objects January 8, 1997 value of atmVpCrossConnectIndex is released by: (1) Setting atmVpCrossConnectRowStatus of all rows identified by this value of atmVpCrossConnectIndex to destroy(6). The agent may release all associated resources, and the atmVpCrossConnectIndex values in the corresponding atmVplTable row are removed. Note that a situation when only a subset of the associated rows are deleted corresponds to a VP topology change. (2) After deletion of the appropriate atmVpCrossConnectEntries, the manager may set atmVplRowStatus to destroy(6) the associated VPLs. The agent releases the resources and removes the associated rows in the atmVplTable. VP Cross-connect Reconfiguration At the discretion of the agent, a VP cross-connect may be reconfigured by adding and/or deleting leafs to/from the VP topology as per the VP cross-connect establishment/retirement procedures. Reconfiguration of traffic/service category parameter values requires release of the VP cross-connect before those parameter values may by changed for individual VPLs." INDEX { atmVpCrossConnectIndex, atmVpCrossConnectLowIfIndex, atmVpCrossConnectLowVpi, atmVpCrossConnectHighIfIndex, atmVpCrossConnectHighVpi } ::= { atmVpCrossConnectTable 1 } AtmVpCrossConnectEntry ::= SEQUENCE { atmVpCrossConnectIndex INTEGER, atmVpCrossConnectLowIfIndex InterfaceIndex, atmVpCrossConnectLowVpi AtmVpIdentifier, atmVpCrossConnectHighIfIndex InterfaceIndex, atmVpCrossConnectHighVpi AtmVpIdentifier, atmVpCrossConnectAdminStatus AtmVorXAdminStatus, Expires 7/8/97 [Page 61] draft ATM Management Objects January 8, 1997 atmVpCrossConnectL2HOperStatus AtmVorXOperStatus, atmVpCrossConnectH2LOperStatus AtmVorXOperStatus, atmVpCrossConnectL2HLastChange AtmVorXLastChange, atmVpCrossConnectH2LLastChange AtmVorXLastChange, atmVpCrossConnectRowStatus RowStatus } atmVpCrossConnectIndex OBJECT-TYPE SYNTAX INTEGER (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique value to identify this VP cross-connect." ::= { atmVpCrossConnectEntry 1 } atmVpCrossConnectLowIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The ifIndex value of the ATM interface for this VP cross-connect. The term low implies that this ATM interface has the numerically lower ifIndex value than the other ATM interface identified in the same atmVpCrossConnectEntry." ::= { atmVpCrossConnectEntry 2 } atmVpCrossConnectLowVpi OBJECT-TYPE SYNTAX AtmVpIdentifier MAX-ACCESS not-accessible STATUS current DESCRIPTION "The VPI value at the ATM interface associated with the VP cross-connect that is identified by atmVpCrossConnectLowIfIndex." ::= { atmVpCrossConnectEntry 3 } atmVpCrossConnectHighIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The ifIndex value of the ATM interface for this VP cross-connect. The term high implies that this ATM interface has the numerically higher Expires 7/8/97 [Page 62] draft ATM Management Objects January 8, 1997 ifIndex value than the other ATM interface identified in the same atmVpCrossConnectEntry." ::= { atmVpCrossConnectEntry 4 } atmVpCrossConnectHighVpi OBJECT-TYPE SYNTAX AtmVpIdentifier MAX-ACCESS not-accessible STATUS current DESCRIPTION "The VPI value at the ATM interface associated with the VP cross-connect that is identified by atmVpCrossConnectHighIfIndex." ::= { atmVpCrossConnectEntry 5 } atmVpCrossConnectAdminStatus OBJECT-TYPE SYNTAX AtmVorXAdminStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The desired administrative status of this bi-directional VP cross-connect." DEFVAL { down } ::= { atmVpCrossConnectEntry 6 } atmVpCrossConnectL2HOperStatus OBJECT-TYPE SYNTAX AtmVorXOperStatus MAX-ACCESS read-only STATUS current DESCRIPTION "The operational status of the VP cross-connect in one direction; (i.e., from the low to high direction)." ::= { atmVpCrossConnectEntry 7 } atmVpCrossConnectH2LOperStatus OBJECT-TYPE SYNTAX AtmVorXOperStatus MAX-ACCESS read-only STATUS current DESCRIPTION "The operational status of the VP cross-connect in one direction; (i.e., from the high to low direction)." ::= { atmVpCrossConnectEntry 8 } atmVpCrossConnectL2HLastChange OBJECT-TYPE Expires 7/8/97 [Page 63] draft ATM Management Objects January 8, 1997 SYNTAX AtmVorXLastChange MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the time this VP cross-connect entered its current operational state in the low to high direction." ::= { atmVpCrossConnectEntry 9 } atmVpCrossConnectH2LLastChange OBJECT-TYPE SYNTAX AtmVorXLastChange MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the time this VP cross-connect entered its current operational in the high to low direction." ::= { atmVpCrossConnectEntry 10 } atmVpCrossConnectRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this entry in the atmVpCrossConnectTable. This object is used to create a cross-connect for cross-connecting VPLs which are created using the atmVplTable or to change or delete an existing cross-connect. This object must be initially set to `createAndWait' or 'createAndGo'. To turn on a VP cross-connect, the atmVpCrossConnectAdminStatus is set to `up'." DEFVAL { active } ::= { atmVpCrossConnectEntry 11 } Expires 7/8/97 [Page 64] draft ATM Management Objects January 8, 1997 -- ATM Virtual Channel (VC) Cross Connect Group -- This group contains configuration and state -- information of point-to-point, -- point-to-multipoint or multipoint-to-multipoint -- VC cross-connects for PVCs. -- This table has read-create access and is used -- to cross-connect the VCLs together in an ATM switch -- or network that belong to a VC connection. -- The atmVcCrossConnectIndex is used to associate -- the related VCLs that are cross-connected together. -- The step-wise procedures described for setting -- up a VP cross-connect are also used for setting up -- a VC cross-connect. atmVcCrossConnectIndexNext OBJECT-TYPE SYNTAX INTEGER (0..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains an appropriate value to be used for atmVcCrossConnectIndex when creating entries in the atmVcCrossConnectTable. The value 0 indicates that no unassigned entries are available. To obtain the atmVpCrossConnectIndex 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 unassigned index." ::= { atmMIBObjects 10 } -- The ATM VC Cross Connect Table atmVcCrossConnectTable OBJECT-TYPE SYNTAX SEQUENCE OF AtmVcCrossConnectEntry MAX-ACCESS not-accessible STATUS current Expires 7/8/97 [Page 65] draft ATM Management Objects January 8, 1997 DESCRIPTION "The ATM VC Cross Connect table. A bi- directional VC cross-connect which cross-connects two end points (i.e., VCLs) is modeled as one entry in this table." ::= { atmMIBObjects 11 } atmVcCrossConnectEntry OBJECT-TYPE SYNTAX AtmVcCrossConnectEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the ATM VC Cross Connect table. This entry is used to model a bi-directional ATM VC cross-connect cross-connecting two end points. Step-wise Procedures to set up a VC Cross-connect Once the entries in the atmVclTable are created, the following procedures are used to cross-connect the VCLs together to form a VCC segment. (1) The manager obtains a unique atmVcCrossConnectIndex by reading the atmVcCrossConnectIndexNext object. (2) Next, the manager creates a set of one or more rows in the ATM VC Cross Connect Table, one for each cross-connection between two VCLs. Each row is indexed by the ATM interface port numbers and VPI/VCI values of the two ends of that cross-connection. This set of rows specifies the topology of the VCC cross-connect and is identified by a single value of atmVcCrossConnectIndex. Negotiated VC Cross-Connect Establishment (2a) The manager creates a row in this table by setting atmVcCrossConnectRowStatus to createAndWait(5). The agent checks the requested topology and the mutual sanity of the ATM traffic parameters and Expires 7/8/97 [Page 66] draft ATM Management Objects January 8, 1997 service categories, i.e., the row creation fails if: - the requested topology is incompatible with associated values of atmVclCastType, - the requested topology is not supported by the agent, - the traffic/service category parameter values associated with the requested row are incompatible with those of already existing rows for this VC cross-connect. [For example, for setting up a point-to-point VC cross-connect, the ATM traffic parameters in the receive direction of a VCL at the low end of the cross-connect must equal to the traffic parameters in the transmit direction of the other VCL at the high end of the cross-connect, otherwise, the row creation fails.] The agent also checks for internal errors in building the cross-connect. The atmVcCrossConnectIndex values in the corresponding atmVclTable rows are filled in by the agent at this point. (2b) The manager promotes the row in the atmVcCrossConnectTable by setting atmVcCrossConnectRowStatus to active(1). If this set is successful, the agent has reserved the resources specified by the ATM traffic parameter and Service category values for each direction of the VC cross-connect in an ATM switch or network. (3) The manager sets the atmVcCrossConnectAdminStatus to up(1) in all rows of this VC cross-connect to turn the traffic flow on. One-Shot VC Cross-Connect Establishment A VC cross-connect may also be established in one step by a set-request with all necessary parameter values and atmVcCrossConnectRowStatus Expires 7/8/97 [Page 67] draft ATM Management Objects January 8, 1997 set to createAndGo(4). In contrast to the negotiated VC cross-connect establishment which allows for detailed error checking i.e., set errors are explicitly linked to particular resource acquisition failures), the one-shot VC cross-connect establishment performs the setup on one operation but does not have the advantage of step-wise error checking. VC Cross-Connect Retirement A VC cross-connect identified by a particular value of atmVcCrossConnectIndex is released by: (1) Setting atmVcCrossConnectRowStatus of all rows identified by this value of atmVcCrossConnectIndex to destroy(6). The agent may release all associated resources, and the atmVcCrossConnectIndex values in the corresponding atmVclTable row are removed. Note that a situation when only a subset of the associated rows are deleted corresponds to a VC topology change. (2) After deletion of the appropriate atmVcCrossConnectEntries, the manager may set atmVclRowStatus to destroy(6) the associated VCLs. The agent releases the resources and removes the associated rows in the atmVclTable. VC Cross-Connect Reconfiguration At the discretion of the agent, a VC cross-connect may be reconfigured by adding and/or deleting leafs to/from the VC topology as per the VC cross-connect establishment/retirement procedures. Reconfiguration of traffic/service category parameter values requires release of the VC cross-connect before those parameter values may by changed for individual VCLs." Expires 7/8/97 [Page 68] draft ATM Management Objects January 8, 1997 INDEX { atmVcCrossConnectIndex, atmVcCrossConnectLowIfIndex, atmVcCrossConnectLowVpi, atmVcCrossConnectLowVci, atmVcCrossConnectHighIfIndex, atmVcCrossConnectHighVpi, atmVcCrossConnectHighVci } ::= { atmVcCrossConnectTable 1 } AtmVcCrossConnectEntry ::= SEQUENCE { atmVcCrossConnectIndex INTEGER, atmVcCrossConnectLowIfIndex InterfaceIndex, atmVcCrossConnectLowVpi AtmVpIdentifier, atmVcCrossConnectLowVci AtmVcIdentifier, atmVcCrossConnectHighIfIndex InterfaceIndex, atmVcCrossConnectHighVpi AtmVpIdentifier, atmVcCrossConnectHighVci AtmVcIdentifier, atmVcCrossConnectAdminStatus AtmVorXAdminStatus, atmVcCrossConnectL2HOperStatus AtmVorXOperStatus, atmVcCrossConnectH2LOperStatus AtmVorXOperStatus, atmVcCrossConnectL2HLastChange AtmVorXLastChange, atmVcCrossConnectH2LLastChange AtmVorXLastChange, atmVcCrossConnectRowStatus RowStatus } atmVcCrossConnectIndex OBJECT-TYPE SYNTAX INTEGER (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique value to identify this VC cross-connect." ::= { atmVcCrossConnectEntry 1 } atmVcCrossConnectLowIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The ifIndex value of the ATM interface for this VC cross-connect. The term low implies that this ATM interface has the numerically lower ifIndex value than the other ATM interface identified in the same atmVcCrossConnectEntry." ::= { atmVcCrossConnectEntry 2 } Expires 7/8/97 [Page 69] draft ATM Management Objects January 8, 1997 atmVcCrossConnectLowVpi OBJECT-TYPE SYNTAX AtmVpIdentifier MAX-ACCESS not-accessible STATUS current DESCRIPTION "The VPI value at the ATM interface associated with the VC cross-connect that is identified by atmVcCrossConnectLowIfIndex." ::= { atmVcCrossConnectEntry 3 } atmVcCrossConnectLowVci OBJECT-TYPE SYNTAX AtmVcIdentifier MAX-ACCESS not-accessible STATUS current DESCRIPTION "The VCI value at the ATM interface associated with this VC cross-connect that is identified by atmVcCrossConnectLowIfIndex." ::= { atmVcCrossConnectEntry 4 } atmVcCrossConnectHighIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The ifIndex value for the ATM interface for this VC cross-connect. The term high implies that this ATM interface has the numerically higher ifIndex value than the other ATM interface identified in the same atmVcCrossConnectEntry." ::= { atmVcCrossConnectEntry 5 } atmVcCrossConnectHighVpi OBJECT-TYPE SYNTAX AtmVpIdentifier MAX-ACCESS not-accessible STATUS current DESCRIPTION "The VPI value at the ATM interface associated with the VC cross-connect that is identified by atmVcCrossConnectHighIfIndex." ::= { atmVcCrossConnectEntry 6 } atmVcCrossConnectHighVci OBJECT-TYPE SYNTAX AtmVcIdentifier MAX-ACCESS not-accessible Expires 7/8/97 [Page 70] draft ATM Management Objects January 8, 1997 STATUS current DESCRIPTION "The VCI value at the ATM interface associated with the VC cross-connect that is identified by atmVcCrossConnectHighIfIndex." ::= { atmVcCrossConnectEntry 7 } atmVcCrossConnectAdminStatus OBJECT-TYPE SYNTAX AtmVorXAdminStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The desired administrative status of this bi-directional VC cross-connect." DEFVAL { down } ::= { atmVcCrossConnectEntry 8 } atmVcCrossConnectL2HOperStatus OBJECT-TYPE SYNTAX AtmVorXOperStatus MAX-ACCESS read-only STATUS current DESCRIPTION "The current operational status of the VC cross-connect in one direction; (i.e., from the low to high direction)." ::= { atmVcCrossConnectEntry 9 } atmVcCrossConnectH2LOperStatus OBJECT-TYPE SYNTAX AtmVorXOperStatus MAX-ACCESS read-only STATUS current DESCRIPTION "The current operational status of the VC cross-connect in one direction; (i.e., from the high to low direction)." ::= { atmVcCrossConnectEntry 10 } atmVcCrossConnectL2HLastChange OBJECT-TYPE SYNTAX AtmVorXLastChange MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the time this VC cross-connect entered its current Expires 7/8/97 [Page 71] draft ATM Management Objects January 8, 1997 operational state in low to high direction." ::= { atmVcCrossConnectEntry 11 } atmVcCrossConnectH2LLastChange OBJECT-TYPE SYNTAX AtmVorXLastChange MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the time this VC cross-connect entered its current operational state in high to low direction." ::= { atmVcCrossConnectEntry 12 } atmVcCrossConnectRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this entry in the atmVcCrossConnectTable. This object is used to create a new cross-connect for cross-connecting VCLs which are created using the atmVclTable or to change or delete existing cross-connect. This object must be initially set to `createAndWait' or 'createAndGo'. To turn on a VC cross-connect, the atmVcCrossConnectAdminStatus is set to `up'." DEFVAL { active } ::= { atmVcCrossConnectEntry 13 } Expires 7/8/97 [Page 72] draft ATM Management Objects January 8, 1997 -- AAL5 Virtual Channel Connection Performance Statistics -- Group -- This group contains the AAL5 -- performance statistics of a VCC at the -- interface associated with an AAL5 entity in an ATM -- host or ATM switch. aal5VccTable OBJECT-TYPE SYNTAX SEQUENCE OF Aal5VccEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains AAL5 VCC performance parameters." ::= { atmMIBObjects 12 } aal5VccEntry OBJECT-TYPE SYNTAX Aal5VccEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This list contains the AAL5 VCC performance parameters." INDEX { ifIndex, aal5VccVpi, aal5VccVci } ::= { aal5VccTable 1 } Aal5VccEntry ::= SEQUENCE { aal5VccVpi AtmVpIdentifier, aal5VccVci AtmVcIdentifier, aal5VccCrcErrors Counter32, aal5VccSarTimeOuts Counter32, aal5VccOverSizedSDUs Counter32 } aal5VccVpi OBJECT-TYPE SYNTAX AtmVpIdentifier MAX-ACCESS not-accessible STATUS current DESCRIPTION "The VPI value of the AAL5 VCC at the interface identified by the ifIndex." ::= { aal5VccEntry 1 } Expires 7/8/97 [Page 73] draft ATM Management Objects January 8, 1997 aal5VccVci OBJECT-TYPE SYNTAX AtmVcIdentifier MAX-ACCESS not-accessible STATUS current DESCRIPTION "The VCI value of the AAL5 VCC at the interface identified by the ifIndex." ::= { aal5VccEntry 2 } 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 } aal5VccSarTimeOuts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of partially re-assembled AAL5 CPCS PDUs which were discarded on this AAL5 VCC at the interface associated with an AAL5 entity because they were not fully re-assembled within the required time period. If the re-assembly timer is not supported, then this object contains a zero value." ::= { aal5VccEntry 4 } aal5VccOverSizedSDUs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of AAL5 CPCS PDUs discarded on this AAL5 VCC at the interface associated with an AAL5 entity because the AAL5 SDUs were too large." ::= { aal5VccEntry 5 } Expires 7/8/97 [Page 74] draft ATM Management Objects January 8, 1997 -- -- The following object may be used in conjunction with -- the atmTrafficDescrParamTable for the creation of -- new table entries. -- atmTrafficDescrParamIndexNext OBJECT-TYPE SYNTAX INTEGER (0..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains an appropriate value to be used for atmTrafficDescrParamIndex when creating entries in the atmTrafficDescrParamTable. The value 0 indicates that no unassigned entries are available. To obtain the atmTrafficDescrParamIndex 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 unassigned index." ::= { atmMIBObjects 13 } Expires 7/8/97 [Page 75] draft ATM Management Objects January 8, 1997 -- Conformance Information atmMIBConformance OBJECT IDENTIFIER ::= { atmMIB 2 } atmMIBGroups OBJECT IDENTIFIER ::= { atmMIBConformance 1 } atmMIBCompliances OBJECT IDENTIFIER ::= { atmMIBConformance 2 } -- Compliance Statements atmMIBCompliance2 MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities including networks which have ATM and AAL5 interfaces." MODULE -- this module -- -- ****** Interface and Traffic Descriptor Support *** -- MANDATORY-GROUPS {atmInterfaceConfGroup2, atmTrafficDescrGroup2 } OBJECT atmInterfaceMaxVpcs MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmInterfaceMaxVccs MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmInterfaceMaxActiveVpiBits MIN-ACCESS read-only DESCRIPTION "Write access is not required. At the ATM UNI the maximum number of active VPI bits configured for use ranges from 0 to 8 only. Implementations may support smaller ranges." Expires 7/8/97 [Page 76] draft ATM Management Objects January 8, 1997 OBJECT atmInterfaceMaxActiveVciBits MIN-ACCESS read-only DESCRIPTION "Write access is not required. Implementations may support smaller ranges." OBJECT atmInterfaceIlmiVpi MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmInterfaceIlmiVci MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmInterfaceMyNeighborIpAddress MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmInterfaceMyNeighborIfName MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmInterfaceSubscrAddress MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmTrafficDescrParamIndexNext DESCRIPTION "This object is only required for systems that support the creation of entries in the atmTrafficDescrParamTable." OBJECT atmTrafficDescrType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmTrafficDescrParam1 MIN-ACCESS read-only DESCRIPTION Expires 7/8/97 [Page 77] draft ATM Management Objects January 8, 1997 "Write access is not required." OBJECT atmTrafficDescrParam2 MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmTrafficDescrParam3 MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmTrafficDescrParam4 MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmTrafficDescrParam5 MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmServiceCategory MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmTrafficDescrRowStatus SYNTAX INTEGER {active(1)} -- subset of RowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required, and only one of the six enumerated values for the RowStatus textual convention need be supported, specifically: active(1)." -- -- ****** DS3 PLCP Support ************************** -- GROUP atmInterfaceDs3PlcpGroup DESCRIPTION "This group is mandatory only for those ATM interfaces which implement the DS3 PLCP layer." -- Expires 7/8/97 [Page 78] draft ATM Management Objects January 8, 1997 -- ****** TC Support ******************************** -- GROUP atmInterfaceTCGroup DESCRIPTION "This group is mandatory only for those ATM interfaces which implement the TC Sublayer." -- -- ****** VPC Support ******************************* -- GROUP atmVpcTerminationGroup2 DESCRIPTION "This group is mandatory only for those ATM interfaces which implement ATM VPLs that terminate VPCs (i.e., ones which are NOT cross-connected to other VPLs)." GROUP atmVplCrossConnectGroup DESCRIPTION "This group is mandatory only for those ATM interfaces which implement ATM VPLs that are not associated with VCLs and are cross-connected to other VPLs for VPCs." GROUP atmVpPvcCrossConnectGroup DESCRIPTION "This group is mandatory only for those ATM interfaces which implement ATM VPLs that are not associated with VCLs and are cross-connected to other VPLs for permanent VPCs (i.e., PVCs). This group is not used to crossconnect a PVC with an SVC to form a Soft PVC." OBJECT atmVplAdminStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmVplReceiveTrafficDescrIndex MIN-ACCESS read-only DESCRIPTION "Write access is not required." Expires 7/8/97 [Page 79] draft ATM Management Objects January 8, 1997 OBJECT atmVplTransmitTrafficDescrIndex MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmVplRowStatus SYNTAX INTEGER {active(1)} -- subset of RowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required, and only one of the six enumerated values for the RowStatus textual convention need be supported, specifically: active(1)." OBJECT atmVplCastType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmVplConnKind MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmVpCrossConnectAdminStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmVpCrossConnectRowStatus SYNTAX INTEGER {active(1)} -- subset of RowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required, and only one of the six enumerated values for the RowStatus textual convention need be supported, specifically: active(1)." -- -- ****** VCC Support ******************************* -- GROUP atmVccTerminationGroup2 DESCRIPTION Expires 7/8/97 [Page 80] draft ATM Management Objects January 8, 1997 "This group is mandatory only for those ATM interfaces which implement ATM VCLs that terminate VCCs (i.e., ones which are NOT cross-connected to other VCLs)." GROUP atmVclCrossConnectGroup DESCRIPTION "This group is mandatory only for those ATM interfaces which implement ATM VCLs that cross-connected to other VCLs for VCCs." GROUP atmVcPvcCrossConnectGroup DESCRIPTION "This group is mandatory only for those ATM interfaces which implement ATM VCLs that are cross-connected to other VCLs for permanent VCCs (i.e., PVCs). This group is not used to crossconnect a PVC with an SVC to form a Soft PVC." OBJECT atmVclAdminStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmVclReceiveTrafficDescrIndex MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmVclTransmitTrafficDescrIndex MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmVccAalType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmVclRowStatus SYNTAX INTEGER {active(1)} -- subset of RowStatus MIN-ACCESS read-only Expires 7/8/97 [Page 81] draft ATM Management Objects January 8, 1997 DESCRIPTION "Write access is not required, and only one of the six enumerated values for the RowStatus textual convention need be supported, specifically: active(1)." OBJECT atmVclCastType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmVclConnKind MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmVcCrossConnectAdminStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmVcCrossConnectRowStatus SYNTAX INTEGER { active(1)} -- subset of RowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required, and only one of the six enumerated values for the RowStatus textual convention need be supported, specifically: active(1)." -- -- ****** AAL5 Support ****************************** -- GROUP aal5VccGroup DESCRIPTION "This group is mandatory for the AAL5 virtual connections only." OBJECT atmVccAal5CpcsTransmitSduSize MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmVccAal5CpcsReceiveSduSize MIN-ACCESS read-only Expires 7/8/97 [Page 82] draft ATM Management Objects January 8, 1997 DESCRIPTION "Write access is not required." OBJECT atmVccAal5EncapsType MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { atmMIBCompliances 2 } Expires 7/8/97 [Page 83] draft ATM Management Objects January 8, 1997 -- Units of Conformance atmInterfaceDs3PlcpGroup OBJECT-GROUP OBJECTS {atmInterfaceDs3PlcpSEFSs, atmInterfaceDs3PlcpAlarmState, atmInterfaceDs3PlcpUASs} STATUS current DESCRIPTION "A collection of objects providing information about DS3 PLCP layer at an ATM interface." ::= { atmMIBGroups 3 } atmInterfaceTCGroup OBJECT-GROUP OBJECTS { atmInterfaceOCDEvents, atmInterfaceTCAlarmState } STATUS current DESCRIPTION "A collection of objects providing information about TC sublayer at an ATM interface." ::= { atmMIBGroups 4 } aal5VccGroup OBJECT-GROUP OBJECTS {atmVccAal5CpcsTransmitSduSize, atmVccAal5CpcsReceiveSduSize, atmVccAal5EncapsType, aal5VccCrcErrors, aal5VccSarTimeOuts, aal5VccOverSizedSDUs } STATUS current DESCRIPTION "A collection of objects providing AAL5 configuration and performance statistics of a VCC." ::= { atmMIBGroups 9 } atmInterfaceConfGroup2 OBJECT-GROUP OBJECTS { atmInterfaceMaxVpcs, atmInterfaceMaxVccs, atmInterfaceConfVpcs, atmInterfaceConfVccs, atmInterfaceMaxActiveVpiBits, atmInterfaceMaxActiveVciBits, atmInterfaceIlmiVpi, atmInterfaceIlmiVci, atmInterfaceMyNeighborIpAddress, atmInterfaceMyNeighborIfName, atmInterfaceCurrentMaxVpiBits, Expires 7/8/97 [Page 84] draft ATM Management Objects January 8, 1997 atmInterfaceCurrentMaxVciBits, atmInterfaceSubscrAddress } STATUS current DESCRIPTION "A collection of objects providing configuration information about an ATM interface." ::= { atmMIBGroups 10 } atmTrafficDescrGroup2 OBJECT-GROUP OBJECTS { atmTrafficDescrType, atmTrafficDescrParam1, atmTrafficDescrParam2, atmTrafficDescrParam3, atmTrafficDescrParam4, atmTrafficDescrParam5, atmTrafficDescrRowStatus, atmServiceCategory, atmTrafficDescrParamIndexNext } STATUS current DESCRIPTION "A collection of objects providing information about ATM traffic descriptor type and the associated parameters." ::= { atmMIBGroups 11 } atmVpcTerminationGroup2 OBJECT-GROUP OBJECTS {atmVplOperStatus, atmVplAdminStatus, atmVplLastChange, atmVplReceiveTrafficDescrIndex, atmVplTransmitTrafficDescrIndex, atmVplRowStatus, atmVplCastType, atmVplConnKind } STATUS current DESCRIPTION "A collection of objects providing information about a VPL at an ATM interface which terminates a VPC (i.e., one which is NOT cross-connected to other VPLs)." ::= { atmMIBGroups 12 } atmVccTerminationGroup2 OBJECT-GROUP OBJECTS {atmVclOperStatus, atmVclAdminStatus, atmVclLastChange, atmVclReceiveTrafficDescrIndex, atmVclTransmitTrafficDescrIndex, atmVccAalType, atmVclRowStatus, atmVclCastType, atmVclConnKind } STATUS current Expires 7/8/97 [Page 85] draft ATM Management Objects January 8, 1997 DESCRIPTION "A collection of objects providing information about a VCL at an ATM interface which terminates a VCC (i.e., one which is NOT cross-connected to other VCLs)." ::= { atmMIBGroups 13 } atmVplCrossConnectGroup OBJECT-GROUP OBJECTS { atmVplReceiveTrafficDescrIndex, atmVplTransmitTrafficDescrIndex, atmVplOperStatus, atmVplRowStatus, atmVplCastType, atmVplConnKind } STATUS current DESCRIPTION "A collection of objects providing information about the VPLs that are cross-connected together." ::= { atmMIBGroups 14 } atmVpPvcCrossConnectGroup OBJECT-GROUP OBJECTS { atmVpCrossConnectAdminStatus, atmVpCrossConnectL2HOperStatus, atmVpCrossConnectH2LOperStatus, atmVpCrossConnectL2HLastChange, atmVpCrossConnectH2LLastChange, atmVpCrossConnectRowStatus, atmVplCrossConnectIdentifier, atmVpCrossConnectIndexNext } STATUS current DESCRIPTION "A collection of objects providing information about a VP cross-connect for PVCs. These objects are not used for Soft PVCs or SVCs." ::= { atmMIBGroups 15 } atmVclCrossConnectGroup OBJECT-GROUP OBJECTS { atmVclReceiveTrafficDescrIndex, atmVclTransmitTrafficDescrIndex, atmVclOperStatus, atmVclRowStatus, atmVclCastType, atmVclConnKind } STATUS current DESCRIPTION "A collection of objects providing information about the VCLs that Expires 7/8/97 [Page 86] draft ATM Management Objects January 8, 1997 are cross-connected together." ::= { atmMIBGroups 16 } atmVcPvcCrossConnectGroup OBJECT-GROUP OBJECTS { atmVcCrossConnectAdminStatus, atmVcCrossConnectL2HOperStatus, atmVcCrossConnectH2LOperStatus, atmVcCrossConnectL2HLastChange, atmVcCrossConnectH2LLastChange, atmVcCrossConnectRowStatus, atmVclCrossConnectIdentifier, atmVcCrossConnectIndexNext } STATUS current DESCRIPTION "A collection of objects providing information about a VC cross-connect for PVCs. These objects are not used for Soft PVCs or SVCs." ::= { atmMIBGroups 17 } Expires 7/8/97 [Page 87] draft ATM Management Objects January 8, 1997 -- Deprecated Definitions - Objects -- atmInterfaceAddressType -- atmTrafficQoSClass -- Deprecated Definitions - Compliance atmMIBCompliance MODULE-COMPLIANCE STATUS deprecated DESCRIPTION "The compliance statement for SNMP entities including networks which have ATM and AAL5 interfaces." MODULE -- this module MANDATORY-GROUPS {atmInterfaceConfGroup, atmTrafficDescrGroup} OBJECT atmInterfaceMaxVpcs MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmInterfaceMaxVccs MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmInterfaceMaxActiveVpiBits MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmInterfaceMaxActiveVciBits MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmInterfaceIlmiVpi MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmInterfaceIlmiVci Expires 7/8/97 [Page 88] draft ATM Management Objects January 8, 1997 MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmInterfaceMyNeighborIpAddress MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmInterfaceMyNeighborIfName MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmTrafficDescrType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmTrafficDescrParam1 MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmTrafficDescrParam2 MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmTrafficDescrParam3 MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmTrafficDescrParam4 MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmTrafficDescrParam5 MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmTrafficQoSClass Expires 7/8/97 [Page 89] draft ATM Management Objects January 8, 1997 MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmTrafficDescrRowStatus SYNTAX INTEGER {active(1)} -- subset of RowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required, and only one of the six enumerated values for the RowStatus textual convention need be supported, specifically: active(1)." GROUP atmInterfaceDs3PlcpGroup DESCRIPTION "This group is mandatory only for those ATM interfaces which implement the DS3 PLCP layer." GROUP atmInterfaceTCGroup DESCRIPTION "This group is mandatory only for those ATM interfaces which implement the TC Sublayer." GROUP atmVpcTerminationGroup DESCRIPTION "This group is mandatory only for those ATM interfaces which implement ATM VPLs that terminate VPCs (i.e., ones which are NOT cross-connected to other VPLs)." GROUP atmVpCrossConnectGroup DESCRIPTION "This group is mandatory only for those ATM interfaces which implement ATM VPLs that are not associated with VCLs and are cross-connected to other VPLs." OBJECT atmVplAdminStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." Expires 7/8/97 [Page 90] draft ATM Management Objects January 8, 1997 OBJECT atmVplReceiveTrafficDescrIndex MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmVplTransmitTrafficDescrIndex MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmVplRowStatus SYNTAX INTEGER {active(1)} -- subset of RowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required, and only one of the six enumerated values for the RowStatus textual convention need be supported, specifically: active(1)." OBJECT atmVpCrossConnectAdminStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmVpCrossConnectRowStatus SYNTAX INTEGER {active(1)} -- subset of RowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required, and only one of the six enumerated values for the RowStatus textual convention need be supported, specifically: active(1)." GROUP atmVccTerminationGroup DESCRIPTION "This group is mandatory only for those ATM interfaces which implement ATM VCLs that terminate VCCs (i.e., ones which are NOT cross-connected to other VCLs)." GROUP atmVcCrossConnectGroup DESCRIPTION "This group is mandatory only for those Expires 7/8/97 [Page 91] draft ATM Management Objects January 8, 1997 ATM interfaces which implement ATM VCLs that are cross-connected to other VCLs." OBJECT atmVclAdminStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmVclReceiveTrafficDescrIndex MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmVclTransmitTrafficDescrIndex MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmVccAalType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmVclRowStatus SYNTAX INTEGER {active(1)} -- subset of RowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required, and only one of the six enumerated values for the RowStatus textual convention need be supported, specifically: active(1)." OBJECT atmVcCrossConnectAdminStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmVcCrossConnectRowStatus SYNTAX INTEGER { active(1)} -- subset of RowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required, and only one Expires 7/8/97 [Page 92] draft ATM Management Objects January 8, 1997 of the six enumerated values for the RowStatus textual convention need be supported, specifically: active(1)." GROUP aal5VccGroup DESCRIPTION "This group is mandatory for the AAL5 virtual connections only." OBJECT atmVccAal5CpcsTransmitSduSize MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmVccAal5CpcsReceiveSduSize MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmVccAal5EncapsType MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { atmMIBCompliances 1 } -- Deprecated Definitions - Groups atmInterfaceConfGroup OBJECT-GROUP OBJECTS { atmInterfaceMaxVpcs, atmInterfaceMaxVccs, atmInterfaceConfVpcs, atmInterfaceConfVccs, atmInterfaceMaxActiveVpiBits, atmInterfaceMaxActiveVciBits, atmInterfaceIlmiVpi, atmInterfaceIlmiVci, atmInterfaceAddressType, atmInterfaceAdminAddr, atmInterfaceMyNeighborIpAddress, atmInterfaceMyNeighborIfName } STATUS deprecated DESCRIPTION "A collection of objects providing configuration information about an ATM interface." Expires 7/8/97 [Page 93] draft ATM Management Objects January 8, 1997 ::= { atmMIBGroups 1 } atmTrafficDescrGroup OBJECT-GROUP OBJECTS { atmTrafficDescrType, atmTrafficDescrParam1, atmTrafficDescrParam2, atmTrafficDescrParam3, atmTrafficDescrParam4, atmTrafficDescrParam5, atmTrafficQoSClass, atmTrafficDescrRowStatus} STATUS deprecated DESCRIPTION "A collection of objects providing information about ATM traffic descriptor type and the associated parameters." ::= { atmMIBGroups 2 } atmVpcTerminationGroup OBJECT-GROUP OBJECTS {atmVplOperStatus, atmVplAdminStatus, atmVplLastChange, atmVplReceiveTrafficDescrIndex, atmVplTransmitTrafficDescrIndex, atmVplRowStatus } STATUS deprecated DESCRIPTION "A collection of objects providing information about a VPL at an ATM interface which terminates a VPC (i.e., one which is NOT cross-connected to other VPLs)." ::= { atmMIBGroups 5 } atmVccTerminationGroup OBJECT-GROUP OBJECTS {atmVclOperStatus, atmVclAdminStatus, atmVclLastChange, atmVclReceiveTrafficDescrIndex, atmVclTransmitTrafficDescrIndex, atmVccAalType, atmVclRowStatus } STATUS deprecated DESCRIPTION "A collection of objects providing information about a VCL at an ATM interface which terminates a VCC (i.e., one which is NOT cross-connected to other VCLs)." ::= { atmMIBGroups 6 } atmVpCrossConnectGroup OBJECT-GROUP Expires 7/8/97 [Page 94] draft ATM Management Objects January 8, 1997 OBJECTS { atmVplReceiveTrafficDescrIndex, atmVplTransmitTrafficDescrIndex, atmVplOperStatus, atmVplRowStatus, atmVpCrossConnectAdminStatus, atmVpCrossConnectL2HOperStatus, atmVpCrossConnectH2LOperStatus, atmVpCrossConnectL2HLastChange, atmVpCrossConnectH2LLastChange, atmVpCrossConnectRowStatus, atmVplCrossConnectIdentifier, atmVpCrossConnectIndexNext } STATUS deprecated DESCRIPTION "A collection of objects providing information about a VP cross-connect and the associated VPLs that are cross-connected together." ::= { atmMIBGroups 7 } atmVcCrossConnectGroup OBJECT-GROUP OBJECTS { atmVclReceiveTrafficDescrIndex, atmVclTransmitTrafficDescrIndex, atmVclOperStatus, atmVclRowStatus, atmVcCrossConnectAdminStatus, atmVcCrossConnectL2HOperStatus, atmVcCrossConnectH2LOperStatus, atmVcCrossConnectL2HLastChange, atmVcCrossConnectH2LLastChange, atmVcCrossConnectRowStatus, atmVclCrossConnectIdentifier, atmVcCrossConnectIndexNext } STATUS deprecated DESCRIPTION "A collection of objects providing information about a VC cross-connect and the associated VCLs that are cross-connected together." ::= { atmMIBGroups 8 } -- {atmMIB 3} has been used by [8]. END Expires 7/8/97 [Page 95] draft ATM Management Objects January 8, 1997 12. Acknowledgments This memo is the result of the work of the AToMMIB Working Group. Expires 7/8/97 [Page 96] draft ATM Management Objects January 8, 1997 13. 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, "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)", RFC 1905, January 1996. [5] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", Internet-Draft, cisco Systems, FTP Software, February 1996. [6] Brown, T.A. and K. Tesink, "Definitions of Managed Objects for SMDS Interfaces", RFC 1694, Bellcore, May 1994. [7] 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., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, April 1993. [8] Michael Noto, Kaj Tesink, "ATM Textual Conventions and OBJECT-IDENTITIES", Internet-Draft, Bellcore, October 1996. [9] "ATM Forum UNI Specification, Version 3.0", September 1993. Expires 7/8/97 [Page 97] draft ATM Management Objects January 8, 1997 [10] "ATM Forum B-ICI Specification, Version 1.0", September 1993. [11] "ATM Forum Private Network-Network Interface Specification, Version 1.0 (PNNI 1.0)", af-sig-0055.000, March 1996. Expires 7/8/97 [Page 98] draft ATM Management Objects January 8, 1997 14. Security Considerations Security issues are not discussed in this memo. 15. Author's Address 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 7/8/97 [Page 99] draft ATM Management Objects January 8, 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 ATM Terminology ....................................... 4 5.1 VCL/VPL and VCC/VPC ................................. 4 5.2 PVC, SVC and Soft PVC ............................... 6 5.3 Traffic Management Parameters ....................... 7 5.3.1 Traffic Policing and Traffic Shaping Parameters .................................................... 7 5.3.2 Cell Loss Priority ................................ 7 5.3.3 QoS Class ......................................... 8 5.3.4 Service Category .................................. 8 5.4 Max Active and Max Current VPI and VCI Bits ......... 8 6 Overview .............................................. 9 6.1 Background .......................................... 10 6.2 Structure of the MIB ................................ 10 6.3 ATM Interface Configuration Group ................... 10 6.4 ATM Interface DS3 PLCP and TC Layer Groups .......... 11 6.5 ATM Virtual Link and Cross-Connect Groups ........... 11 7 Application of MIB II to ATM .......................... 11 7.1 The System Group .................................... 11 7.2 The Interface Group ................................. 11 7.2.1 Support of the ATM Cell Layer by ifTable .......... 12 8 Support of the AAL3/4 Based Interfaces ................ 14 9 Support of the AAL5 Managed Objects ................... 15 9.1 Managing AAL5 in a Switch ........................... 15 9.2 Managing AAL5 in a Host ............................. 16 9.3 Support of AAL5 by ifTable .......................... 18 9.4 Support of Proprietary Virtual Interface by ifT- able ............................................... 20 9.5 AAL5 Connection Performance Statistics Group ........ 21 10 ILMI MIB and the ATM Managed Objects ................. 22 11 Definitions .......................................... 25 12 Acknowledgments ...................................... 96 13 References ........................................... 97 14 Security Considerations .............................. 99 15 Author's Address ..................................... 99 Expires 7/8/97 [Page 100] --=====================_855877031==_ 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 _/ _/ _/ _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ --=====================_855877031==_--   Received: from cnri by ietf.org id aa01046; 14 Feb 97 4:02 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa19064; 14 Feb 97 4:02 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 DAA14609 for ; Fri, 14 Feb 1997 03:39:21 -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 AAA01389 for ; Fri, 14 Feb 1997 00:38:51 -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 AAA26662 for ; Fri, 14 Feb 1997 00:36:09 -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 AAA16645 for ; Fri, 14 Feb 1997 00:38:33 -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 AAA26828 for ; Fri, 14 Feb 1997 00:38:49 -0800 (PST) Received: by sutter.NSD.3Com.COM id AA13458 (5.65c/IDA-1.4.4-910730 for atommib@thumper.bellcore.com); Fri, 14 Feb 1997 00:39:08 -0800 Date: Fri, 14 Feb 1997 00:39:08 -0800 From: Faye Ly Message-Id: <199702140839.AA13458@sutter.NSD.3Com.COM> To: atommib@thumper.bellcore.com Subject: Difference between 08 and 09 supp MIB Content-Type: X-sun-attachment ---------- X-Sun-Data-Type: text X-Sun-Data-Description: text X-Sun-Data-Name: text X-Sun-Content-Lines: 12 Hi, Attatched is the change log between and . Please disregard the date posted in the 09 draft. I do intend to post another draft before the next IETF due to the pending issues. Thanks. -faye fayely@3com.com (408)764-6576 ---------- X-Sun-Data-Type: default X-Sun-Data-Description: default X-Sun-Data-Name: TODO.1296 X-Sun-Content-Lines: 135 Change Log of the 1. Change Network to Service throughout the document where applicable. done 2. Put comments about MIB tables into the DESCRIPTION clauses of the tables. (So this is not missing after mibstrip program. Actually mibstrip doesn't do this on my MIB?? James) 3. Rename atmVclAddrBindTable to atmVclAddrTable. (To make this be consistent to the atmAddrVclTable). done 4. Fix conformance of the atmVclAddrTable and atmAddrVclTable and atmVclGenTable. Table Host Switch Service _____________________________________________________ atmSvcVcCrossConnectTable | | Y | Y | atmSvcVpCrossConnectTable | | Y | Y | atmSigTable | Y | Y | Y | atmSigSupportTable | | Y | Y | atmSigDescrParamTable | Y | | | atmIfAdminAddrTable | | Y | Y | atmVclAddrBindTable | Y | | | atmAddrVclTable | Y | Y | Y | atmVplStatTable | Y | Y | Y | atmVplLogicalPortTable | Y | Y | Y | atmVclStatTable | Y | Y | Y | atmVclGenTable | Y | Y | Y | atmInterfaceExtTable | Y | Y | Y | atmSrvcRegTable | Y | Y | Y | Table 1: MIB structure into Table Host Switch Service _____________________________________________________ atmSvcVcCrossConnectTable | | Y | Y | atmSvcVpCrossConnectTable | | Y | Y | > atmSigStatTable | Y | Y | Y | atmSigSupportTable | | Y | Y | atmSigDescrParamTable | Y | | | atmIfAdminAddrTable | | Y | Y | > atmVclAddrTable | Y | ? | ? | > atmAddrVclTable | Y | | | atmVplStatTable | Y | Y | Y | atmVplLogicalPortTable | Y | Y | Y | atmVclStatTable | Y | Y | Y | > atmVclGenTable | Y | | | atmInterfaceExtTable | Y | Y | Y | atmSrvcRegTable | Y | Y | Y | Table 1: MIB structure done 5. Add a new table aal5VccStatTable. (For host only). INDEX { ifIndex, aal5VccVpi, aal5VccVci } { aal5VccStatTotalErrors - all Errors occurred in the AAL5 layer for this VCC. aal5VccInpkts - the ones forwarded or ready to be forwarded to the upper layers only aal5VccOutpkts - the ones received by the AAL5 layer from the users of the AAL5 only aal5VccInOctets - excluding the header aal5VccOutOctets - excluding the header } done 6. Change SPVC to Soft PVC. (per PNNI spec.) ?? Can't find it 7. Per Mickey's comments. Fix all the editorial errors. 7.1 Change local/remote -> CalledParty/CallingParty 7.2 Change conformance atmSrvcRegTable to net/service and delete viaIlmi enum. for atmSrvcRegSource. 7.3 Add clause for Soft PVC support in the atmVclCrossConnectTable. 7.4 Cleanup section 6.3.3 to reflect the concept of ATM interface as opposed to signalling suit. Also add the new enumeration for IISP 4.0. 7.5 Delete description of broadband bearer information in section 6.3.5 since it is not specified in this table. Add a clause to clarify the tables that support AAL5 parameters. 7.6 Move atmSrvcRegIndex as the first index. Rename atmSrvcRegTable to atmIlmiSrvcRegTable. 7.7 Clarify the cross-connects of PVC/PVPs are defined in [1] and SVC/SVP are defined in this MIB. 7.8 ATM VPL and VCL SVC Cross-Connect Tables Cleanup the description text. Also add description of Soft PVCs in these two tables. 7.9 Replace Emitt by Emit. Move cause 88 from atmSigEmitUnavailRoutes to atmSigDetectCldPtyEvents and atmSigEmitCLdPtyEvents. 7.10 Delete atmSigDescrParamAalMode. 7.11 Add enum null for object atmSigDescrParamAalSscsType. 7.12 Fix conformances to reflect the switch/service/host groupings. Done 8. Delete the text describing the ATM signalling entity. Mickey to take it to the mailing list. Change atmSigTable to atmSigStatTable. Remove all ATM signalling configuration parameters. done. 9. Changed atmInterfaceExtTable as per Steve's proposal. done. 10. Added 1. Objects to be added to atmInterfaceExtTable 2. A new atmIlmiNetworkPrefixTable (per interface) per Mickey's Management of ILMI proposal. done.   Received: from cnri by ietf.org id aa01094; 14 Feb 97 4:05 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa19261; 14 Feb 97 4: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 DAA14570 for ; Fri, 14 Feb 1997 03:34:26 -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 AAA01215 for ; Fri, 14 Feb 1997 00:33:55 -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 AAA26477 for ; Fri, 14 Feb 1997 00:31:13 -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 AAA16597 for ; Fri, 14 Feb 1997 00:33:37 -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 AAA26782 for ; Fri, 14 Feb 1997 00:33:53 -0800 (PST) Received: by sutter.NSD.3Com.COM id AA13440 (5.65c/IDA-1.4.4-910730 for atommib@thumper.bellcore.com); Fri, 14 Feb 1997 00:34:12 -0800 Date: Fri, 14 Feb 1997 00:34:12 -0800 From: Faye Ly Message-Id: <199702140834.AA13440@sutter.NSD.3Com.COM> To: atommib@thumper.bellcore.com Subject: ATM Admin Address Table 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: atmaddr.proposal X-Sun-Content-Lines: 77 Mickey, I saw that you proposed a "atmSwitchAddressTable" in the email "Management of ILMI". There is something I don't understand, looking at this table seems to indicate that we should keep the orginal atmIfAdminAddrTable as the place where the service provider can have multiple ATM addresses per ATM interface and use the new table "atmSwitchAddressTable" for the ILMI registered ATM addresses only? Has this been agreed by this list? If this is the case, I guess I will just remove the "dynamic" code point from the atmIfAdminAddrSource. Any oponion? -faye >atmSwitchAddressTable OBJECT-TYPE > SYNTAX SEQUENCE OF AtmSwAddrEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "This table contains one or more ATM endsystem > addresses on a per switch basis. These addresses are > used to identify the switch. > > When no ILMI network prefixes are configured for > certain interfaces, network prefixes based on the > switch address(es) may be used for ILMI address > registration." > ::= { atm2MIBObjects xx } > >atmSwitchAddressEntry OBJECT-TYPE > SYNTAX AtmSwitchAddressEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "An entry in the atmSwitchAddressTable." > INDEX { atmSwitchAddressIndex } > ::= { atmSwitchAddressTable 1 } > >AtmSwitchAddressEntry ::= > SEQUENCE { > atmSwitchAddressIndex Integer32, > atmSwitchAddressAddress AtmAddr, > atmSwitchAddressRowStatus RowStatus > } > >atmSwitchAddressIndex OBJECT-TYPE > SYNTAX Integer32 (1..65535) > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "An arbitrary index used to enumerate the ATM > endsystem addresses for this switch." > ::= { atmSwitchAddressEntry 1 } > >atmSwitchAddressAddress OBJECT-TYPE > SYNTAX OCTET STRING (SIZE(13|20)) > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "An ATM endsystem address or address prefix used to > identify this switch. When no ESI or SEL field is > specified, the switch may generate the ESI and SEL > fields automatically to obtain a complete 20-byte ATM > endsystem address." > ::= { atmSwitchAddressEntry 2 } > >atmSwitchAddressRowStatus OBJECT-TYPE > SYNTAX RowStatus > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "Used to create, delete, activate, and de-activate > addresses used to identify this switch." > ::= { atmSwitchAddressEntry 3 }   Received: from cnri by ietf.org id aa01129; 14 Feb 97 4:09 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa19462; 14 Feb 97 4:08 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 DAA14559 for ; Fri, 14 Feb 1997 03:33:02 -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 AAA01146; Fri, 14 Feb 1997 00:32:04 -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 AAA26416; Fri, 14 Feb 1997 00:29:23 -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 AAA16582; Fri, 14 Feb 1997 00:31: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 AAA26778; Fri, 14 Feb 1997 00:31:59 -0800 (PST) Received: by sutter.NSD.3Com.COM id AA13436 (5.65c/IDA-1.4.4-910730); Fri, 14 Feb 1997 00:32:15 -0800 Date: Fri, 14 Feb 1997 00:32:15 -0800 From: Faye Ly Message-Id: <199702140832.AA13436@sutter.NSD.3Com.COM> To: internet-drafts@CNRI.Reston.VA.US, atommib@thumper.bellcore.com Subject: Posting 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: draft-ietf-atommib-atm2-09.txt X-Sun-Content-Lines: 5643 draft Supplemental ATM Management Objects December 1996 Definitions of Supplemental Managed Objects for ATM Management December 1996 Faye Ly (editor) 3Com Corporation fayely@3com.COM Michael Noto (editor) Bell Communications Research noto@cc.bellcore.com Andrew Smith (editor) Extreme Networks ansmith@ix.netcom.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 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". Expires XX [Page 1] draft Supplemental ATM Management Objects December 1996 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, and services in addition to those defined in the ATM MIB [1], to provide additional support for the management of: - ATM Switched Virtual Connections (SVCs) - ATM Permanent Virtual Connections (PVCs) 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. 3. Change Log This section tracks changes made to the revisions of the Internet Drafts of this document. It will be deleted when the document is published as an RFC. Two additions were added to this document dated September 1996: 1) The Service registry table which provide ATM service configuration information. and 2) ATM traps. 4. The SNMPv2 Network Management Framework The SNMPv2 Network Management Framework consists of four major components. They are: 0 RFC 1442 [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 1445 [4] which defines the administrative and other architectural aspects of the framework. Expires XX [Page 2] draft Supplemental ATM Management Objects December 1996 0 RFC 1448 [5] which defines the protocol used for network access to managed objects. The Framework permits new objects to be defined for the purpose of experimentation and evaluation. 5. 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. 6. 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 the following areas: - ATM Switch Support - ATM Service Support - ATM Host Support In addition, this memo also provides ATM trap support. 6.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 and interface management (RFC 1213 and RFC 1573), 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 [15] and LAN Emulation [14]. These MIB modules are outside the scope of this specification. Expires XX [Page 3] draft Supplemental ATM Management Objects December 1996 This MIB module also requires the use of the ATM MIB module defined in [1]. ATM Endpoint applications such as ATM LAN Emulation or Classical IP-over-ATM Clients and Servers use ATM to establish SVC/PVC connections for exchanging control and data information. The agents of these ATM applications must provide the network manager with information on the SVC/PVCs in use and which applications are using them. The information can be made generic so as to apply to all ATM applications. This memo proposes extensions to the ATM MIB [1] in order to support this. The current specification of this supplemental ATM MIB is based on SNMPv2 SMI. 6.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 Expires XX [Page 4] draft Supplemental ATM Management Objects December 1996 SwitchA and SwitchC) Figure 1: Examples of Virtual Path Links, Virtual Path Connection, and Virtual Path Segment Expires XX [Page 5] draft Supplemental ATM Management Objects December 1996 _____ _______ _______ _______ _____ | |____| |____| |____| |____| | |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 6.3. Supported Functions The managed ATM objects are arranged as follows: Table Host Switch Service _____________________________________________________ atmSvcVcCrossConnectTable | | Y | Y | atmSvcVpCrossConnectTable | | Y | Y | atmSigStatTable | Y | Y | Y | atmSigSupportTable | | Y | Y | atmSigDescrParamTable | Y | | | atmIfAdminAddrTable | | Y | Y | atmVclAddrTable | Y | ? | ? | atmAddrVclTable | Y | | | atmVplStatTable | Y | Y | Y | atmVplLogicalPortTable | Y | Y | Y | atmVclStatTable | Y | Y | Y | atmVclGenTable | Y | | | atmAal5VclStatTable | Y | | | Expires XX [Page 6] draft Supplemental ATM Management Objects December 1996 atmInterfaceExtTable | Y | Y | Y | atmIlmiSrvcRegTable | | Y | Y | atmIlmiNetworkPrefixTable | | Y | Y | Table 1: MIB structure 6.3.1. ATM SVC VC Cross Connect Table This table provides the SVC Cross Connect information. The equivalent PVC VC Cross Connect table is defined in [1]. This table also includes cross-connect information for Soft PVCs. This group is used to model a bi-directional point-to-point, point-to-multipoint or multipoint-to-multipoint SVC VC cross- connect. This table has read-only access and is used to monitor the cross-connects which connect the VCLs together in an ATM switch or network that belong to a VC connection. The atmSvcVcCrossConnectIndex is used to associate the related SVC VCLs that are cross-connected together. The atmSvcVcCrossConnectRowStatus object has read-write access to allow for tear-down. The ATM SVC VC Cross Connect Table models each bi-directional Switched Virtual Circuit (SVC) VC cross-connect as a set of entries in the atmSvcVcCrossConnectTable. A point-to-point VC cross-connect is modeled as one entry; a point-to-multipoint (N leafs) VC cross-connect as N entries in this table; and a multipoint-to-multipoint (N parties) VPC cross-connect as N(N-1)/2 entries in this table. In the latter cases, all the N (or N(N-1)/2) entries are associated with a single VPC cross-connect by having the same value of atmSvcVcCrossConnectIndex. _________________________________________ | | Low | ATM Switch or Network | High port| | port _____|>> from low to high VC traffic flow >>|______ |<< from high to low VC traffic flow <<| | | |_______________________________________| Expires XX [Page 7] draft Supplemental ATM Management Objects December 1996 -- Figure 9: VC Cross-Connect Model The terms low and high are chosen to represent numerical ordering of the two interfaces associated with a VPC cross- connect. That is, the ATM interface with the lower value of ifIndex is termed 'low', while the other ATM interface associated with the VPC cross-connect is termed 'high'. This terminology is used to provide directional information; for example, the atmSvcVcCrossConnectL2HOperStatus applies to the low->high direction, and atmSvcVcCrossConnectH2LOperStatus applies to the high->low direction. 6.3.2. ATM SVC VP Cross Connect Table This table provides the SVC VP Cross Connect information. The equivalent PVC VP Cross Connect table is defined in [1]. This table also includes cross-connect information for Soft PVPs. This group contains configuration and state information of all SVC VP point-to-point, point-to-multipoint, or multipoint-to- multipoint VP cross-connects. This table has read-only access and can be used to monitor the cross-connects which connect the VPLs together in an ATM switch or network. The atmSvcVpCrossConnectIndex is used to associate the related SVC VPLs that are cross-connected together. The atmSvcVpCrossConnectRowStatus object has read- write access to allow for tear-down. The ATM SVC VP Cross Connect Table models each bi-directional Switched Virtual Circuit (SVC) VP cross-connect as a set of entries in the atmSvcVpCrossConnectTable. A point-to-point VPC cross-connect is modeled as one entry; a point-to-multipoint (N leafs) VPC cross-connect as N entries in this table; and a multipoint-to-multipoint (N parties) VPC cross-connect as N(N-1)/2 entries in this table. In the latter cases, all the N (or N(N-1)/2) entries are associated with a single VPC cross-connect by having the same value of atmSvcVpCrossConnectIndex. _________________________________________ | | Expires XX [Page 8] draft Supplemental ATM Management Objects December 1996 Low | ATM Switch or Network | High port| | port _____|>> from low to high VPC traffic flow >>|______ |<< from high to low VPC traffic flow <<| | | |_______________________________________| -- Figure 9: VPC Cross-Connect Model The terms low and high are chosen to represent numerical ordering of the two interfaces associated with a VPC cross- connect. That is, the ATM interface with the lower value of ifIndex is termed 'low', while the other ATM interface associated with the VPC cross-connect is termed 'high'. This terminology is used to provide directional information; for example, the atmSvcVpCrossConnectL2HOperStatus applies to the low->high direction, and atmSvcVpCrossConnectH2LOperStatus applies to the high->low direction. 6.3.3. ATM Interface Signalling Statistics Table This table provides statistical information of the signalling entity. A signalling entity can be deployed over an ATM interface as defined in the atmInterfaceConfTable [1], a logical ATM interface defined in section 6.3.10.1 in this document or a proprietary virtual interface as described atmInterfaceExtTable. To monitor the signalling entity, a few counters are provided. They are defined as: 6.3.3.1. SSCOP Counters This group contains information on the ATM SSCOP signalling layer and must be supported by signalling entities. 6.3.3.2. Unsupported Service Failures This group contains information on the setup failures that occur when setting up an ATM SVC. Maintaining counters for each individual signalling cause codes would result in a large number of counters. Instead, this memo uses an approach that lumps events into the following categories: - Route Unavailability Counter Expires XX [Page 9] draft Supplemental ATM Management Objects December 1996 - Resources Unavailability Counter - Called Party Events Counter - Message Error Counter - Calling Party Events Counter - Timer Expiries Counter - Restart Activity Counter In addition, a Setup Attempts Counter was added to keep track of the number of Setup attempts made (both successful and unsuccessful). Setup attempts are counted both at the receiving and sending sides of the signalling entity. For example, the object atmSigDetectSetupAttempts counts the number of setup attempts detected on the interface and the object atmSigEmitSetupAttempts counts the number of setup attempts emited from this interface. Thus, a switch will increment both the receiving and emiting counters when relaying a setup attemp. 6.3.3.3. ATM Signalling Layer Protocol Errors This group contains information on the Protocol Errors that occur at the signalling layer when establishing an ATM SVC. 6.3.3.4. UNI Signalling Sub-layer Statistics Statistics per VCL are needed in order to find out the usage of VCL resources by ATM applications. Additionally, to monitor the usage and health of a UNI signalling entity, some counters are needed per UNI signalling entity. Two new objects are added to count the number of connections established. One for incoming SVCs and one for outgoing SVCs. Note that some counters do not apply to the proprietary virtual interface such as the atmSigSSCOPConEvents, atmSigSSCOPErrdPdus, atmSigSigMsgErrors and atmSigSigRestarts. 6.3.4. ATM Signalling Capability Support A number of Information Elements may or may not be supported by ATM switches or ATM Service. Hence, for trouble isolation Expires XX [Page 10] draft Supplemental ATM Management Objects December 1996 it is important to keep track which particular Information Elements are supported. The corresponding group of objects must be supported by switches or services supporting SVCs, and indicate whether the following Information Elements are enabled/disabled: 1) Calling party number 2) Calling party subaddress 3) Called party subaddress 4) Broadband high layer information 5) Broadband low layer information 6) Broadband Repeat Indicator 7) AAL parameters The last parameter, Preferred Carrier Pre-Subscription, identifies the carrier to which intercarrier calls originated from this interface are routed when transit network selection information is not provided by the calling party. 6.3.5. Signalling Descriptor Parameter Table This table extends the ATM VCL table of the ATM MIB [1] to include all other necessary signalling information as specified in the ATM Forum UNI Specifications [9] and [10]. A user can create an entry with all signalling parameters and later use that entry to specify the signalling characteristics of SVCs. Some of the signalling parameters such as the AAL5 parameters information element is reflected in the VCL and VPL tables, and this table only contains the remaining AAL5 parameters information. Signalling attributes can be grouped into following categories: 1) ATM Adaptation Layer Parameters Expires XX [Page 11] draft Supplemental ATM Management Objects December 1996 Information in this group are captured in the ATM Signalling Descriptor Parameter Table defined in this memo. Please refer to section 5.4.5.5 of [9] and [10]. 2) Broadband High Layer Information Information in this group are captured by the ATM Signalling Descriptor Parameter Table defined in this memo. Please refer to section 5.4.5.8 of [9] and [10]. 3) Broadband Low Layer Information Information in this group are captured by the ATM Signalling Descriptor Parameter Table defined in this memo. Please refer to section 5.4.5.9 of [9] and [10]. 6.3.6. ATM Interface Administrative Address Table This table contains an ATM Interface Administrative Address Table (atmIfAdminAddrTable) which lists valid addresses for calls to and from a given interface. One of these numbers shall be specified as the "default" number. See also section 6. 6.3.7. ATM VPI/VCI to Address Mapping Table In the atmVclAddrTable, the object atmVclAddrAddr can either be an ATM Local Address or an ATM Remote Address which represent the two endpoint addresses of a VCL. ATM Local Address identifies the local endpoint of the VCL represented by this agent. While, the ATM Remote address represents the address of the ATM application at the other end of the VCL. 6.3.8. ATM Address to VPI/VCI Mapping Table This table provides an alternative way to retrieve the atmVclTable. This table can be used to retrieve the indexing to the atmVclTable by an ATM address. 6.3.9. ATM VPL Statistics Table The atmVplStatTable includes per VPL cell counters. The VPL cell counters count the valid ATM cells. The valid ATM cells Expires XX [Page 12] draft Supplemental ATM Management Objects December 1996 include the user and OAM cells but exclude the physical layer (e.g. idle cells) and unassigned cells. Cells coming in to an ATM managed system are counted differently with the high Cell Loss Priority (CLP=0) or low Cell Loss Priority (CLP=1). The cells are tagged, passed or discarded depending on the incoming CLP value and the policed cell rate by the "traffic policing" entity in the ATM managed system. Refer to [9] and [10] for the description of the traffic policing. In the switch where the traffic policing is not supported, cells are passed or discarded depending on the bandwidth of the switching fabric. The Output Tagged Cells counter, in this case, is always zero. _______________ | ATM Managed | Input | System | Output CLP=0 cells| | CLP=0 cells ---------->| |-----------> CLP=1 cells| (traffic | CLP=1 cells ---------->| policing |-----------> | entity) | Tagged cells (CLP=1) |_____________|-----------> |Discard | Discard |CLP=0 | CLP=1 |cells | cells | | V V Figure 5. ATM Cell Counters per VPL In this table, cells coming into and out of the managed ATM system are counted as the total number of cells and the cells with the CLP=0. The CLP=1 counter is derived by substracting CLP=0 cells from the total cells. In addition, cells that are tagged on the output are also counted. The output CLP=1 cells equals to the total cells out count minus both the CLP=0 cells and the tagged cells. Expires XX [Page 13] draft Supplemental ATM Management Objects December 1996 6.3.10. ATM VPL Logical Port Table The ATM VPL Logical Port Table includes all ATM logical port interface configuration information. 6.3.10.1. ATM Logical Port Interface The interface type "ATM Logical Port" (ifType=80) is defined to allow the representation of a VP Tunnel, which is a VPL used as a trunk connection (most likely between devices that are not physically adjacent), providing for multiplexing and demultiplexing of VCs on the VP. Figure 6 illustrates such a VP Tunnel. Note: the "ATM Logical Port" interface is more of a logical port, compared with an interface of type "ATM" which is more of a physical port that provides for the transport of many VP and VC connections between adjacent devices. Expires XX [Page 14] draft Supplemental ATM Management Objects December 1996 <------VP Tunnel------> ATM Switch A ATM Switch B ------------ ----------- |ATM |_____________|ATM | |X-Connect | . |X-Connect | VCL1 |Point | VPL1 . VPL2 |Point | VCL4 O---------|----X-----|----- . -----|----X-----|-----O | X-----|----- . -----|----X | | | |_____________| | | ------------ ------------ | VCL2 | VCL3 O O Figure 6: Virtual Path Tunnel In Figure 6, a VP tunnel (denoted as VPL1 by Switch A, and as VPL2 by Switch B) is used to connect VCL1 with VCL4 and VCL2 with VCL3. Figure 6 shows only one VP tunnel, but there can be multiple VP tunnels over the same physical interface. A particularly useful VP tunnel scenario is tunneling across a public network that does not support signalling. In Figure 6 above, assume Switches A and B are private switches that signal over the VP to set up connections transparently through the public network. The public network would just transport a PVC VP between the two switches. Because the VP Tunnel constitutes an interface between two ATM devices that are not necessarily physically adjacent, most of the management information pertaining to the interface may differ for the tunnel, including: - active VPI/VCI fields (the tunnel may be a subset of the parent interface). - maximum number of VCCs - configured VCCs - ILMI VPI/VCI values - ATM address type - ATM administrative address - received/transmitted cells. Expires XX [Page 15] draft Supplemental ATM Management Objects December 1996 6.3.10.2. How to create an ATM logical interface The ATM Logical Port Interface Table is used only by devices supporting VP tunnels. To create an ATM Logical Port interface via SNMP: - Create a VPL (e.g., VPI=a on an existing ATM interface which has ifIndex=x) in the atmVplTable. - Set the object atmVplLogicalPortDef to isLogicalIf. A new row in the ifTable is then created by the agent, with ifIndex=y, to represent the ATM Logical Port interface. The object atmVplLogicalPortIndex is also set to y by the agent to represent the ifIndex value of the ATM Logical Port interface. - The ifEntry values are set for the ATM Logical Port interface (ifIndex=y) as discussed in RFC 1695, with the following exceptions: * ifType - a new enumerated value of "80" was added to IANAifType, specifying an "ATM Logical Port" interface. * ifSpeed - The total bandwidth in bits per second for use by the ATM layer. Computed from the traffic descriptor for the VPL. * ifOperStatus - determined hierarchically, depending on the state of the physical atm-cell layer interface beneath it, and the ILMI on the VP. * ifInOctets, ifOutOctets - support of these objects is not mandatory for ATM Logical Port interfaces. * ifInErrors - always zero, HEC errors are specified for the atm cell-layer interface beneath it. * ifInUnknownProtos - always zero, errors are specified for the atm cell-layer interface beneath it. - The atmInterfaceConfEntry values are set as discussed in [1], with the following exceptions: * atmInterfaceMaxVpcs - 0. * atmInterfaceConfVpcs - 0. * atmInterfaceIlmiVpi - VPI of the VP Expires XX [Page 16] draft Supplemental ATM Management Objects December 1996 tunnel. - An entry is created in the ifStackTable, with values: ifStackHigherLayer=y, ifStackLowerLayer=x. - VCLs defined on the VP tunnel are indexed by ifIndex=y,VPI=a,VCI. 6.3.11. ATM VCL Statistics Table The atmVclStatTable includes per VCL cell counters. The VCL cell counters count the valid ATM cells. The valid ATM cells include the user and OAM cells but exclude the physical layer (e.g. idle cells) and unassigned cells. Cells coming in to an ATM managed system are counted differently with the high Cell Loss Priority (CLP=0) or low Cell Loss Priority (CLP=1). The cells are tagged, passed or discarded depending on the incoming CLP value and the policed cell rate by the "traffic policing" entity in the ATM managed system. Refer to [9] and [10] for the description of the traffic policing. In the switch where the traffic policing is not supported, cells are passed or discarded depending on the bandwidth of the switching fabric. The Output Tagged Cells counter, in this case, is always zero. _______________ | ATM Managed | Input | System | Output CLP=0 cells| | CLP=0 cells ---------->| |-----------> CLP=1 cells| (traffic | CLP=1 cells ---------->| policing |-----------> | entity) | Tagged cells (CLP=1) |_____________|-----------> |Discard | Discard |CLP=0 | CLP=1 |cells | cells | | V V Figure 7. ATM Cell Counters per VCL Expires XX [Page 17] draft Supplemental ATM Management Objects December 1996 In this table, cells coming into and out of the managed ATM system are counted as the total number of cells and the cells with the CLP=0. The CLP=1 counter is derived by substracting CLP=0 cells from the total cells. In addition, cells that are tagged on the output are also counted. The output CLP=1 cells equals to the total cells out count minus both the CLP=0 cells and the tagged cells. 6.3.12. ATM VC General Information Table This table contains the general information for each VCs. It provides an index to the atmSigDescrParamTable defined in this MIB. This table is an extention to the atmVclTable defined in the ATM MIB [1]. 6.3.13. ATM Interface Configuration Extention Table The ATM Interface Configuration Extention Table contains ATM interface information that supplements the atmInterfaceConfTable defined in [1]. It includes the configuration information of the signalling and ILMI. A network manager can configure the signalling entity to run a specific interface type (i.e. signalling protocol and version) such as ITU-U DSS2, ATM Forum UNI 3.1, PNNI 1.0 or BICI 2.0. It can also dictate the side of the signalling entity. For example, if a signalling entity is configured to run ATM Forum UNI 3.1, it has to be told to run as either the network side or the user side of the UNI. The objects atmInterfaceConfigSigType and atmInterfaceConfigSide are used for configuration and the objects atmInterfaceActualSigType and atmInterfaceActualSigSide are used for reading back the actual signalling configuration. The following table describes all the combinations of the configuration of the signalling entity: atmInterfaceConfigSigType atmInterfaceConfigSigSide ---------------- ---------------- autoConfig other ituDss2 user/network atmfUni3Dot0 user/network Expires XX [Page 18] draft Supplemental ATM Management Objects December 1996 atmfUni3Dot1 user/network atmfUni4Dot0 user/network atmfIisp3Dot0 user/network atmfIisp3Dot1 user/network atmfIisp4Dot0 user/network atmfPnni1Dot0 other atmfBici2Dot0 other When the value of the object atmInterfaceConfigSigType is configured to autoConfig(2), the signalling type is determined via the ATM Forum ILMI auto-configuration procedures [22]. There is no need to set the signalling side since it should be a derived value. The PNNI and BICI interfaces are always symmetric so setting the signalling side is also not necessary. This table also includes the configured and negotiated maximum VPI value per ATM interface, and the configured and negotiated minimum VCI value per ATM interface. Refer to [21] Sections 8.2.3.8 through 8.2.3.10 for a detailed description. The following figure provides an example how the current minimum VCI values are derived from the configured minimum VCI values and the neighboring minimum VCI values: +--------+ +--------+ +--------+ | ATM | IF a IF b | ATM | IF c IF d | ATM | | Device |--------------| Device |--------------| Device | +--------+ +--------+ +--------+ IF a: Configured Min SVCC VCI = 32 (configured) Current Min SVCC VCI = 40 (negotiated) IF b: Configured Min SVCC VCI = 40 (configured) Current Min SVCC VCI = 40 (negotiated) IF c: Configured Min SVCC VCI = 32 (configured) Current Min SVCC VCI = 32 (negotiated) IF d: Configured Min SVCC VCI = 32 (configured) Current Min SVCC VCI = 32 (negotiated) Expires XX [Page 19] draft Supplemental ATM Management Objects December 1996 (between IF a and IF b, the maximum of the two atmInterfaceConfMinSvccVci is 40, so both interfaces set their atmInterfaceCurrentMinSvccVci to 40. Since IF c and IF d both are configured with atmInterfaceConfMinSvccVci of 32, they set their atmInterfaceCurrentMinSvccVci to 32.) Figure 8 6.3.14. ATM Services Registration Table This table contains information used by ATM devices to locate ATM network services. ATM network services such as CIP ARP server or LECS, can be created by the network manager or learned via ILMI. Entries in this table can either be exported to the adjacent devices via ILMI to all or a few user selected ATM interfaces. As an example, let's assume that: - an ATM switch X has three interfaces if1, if2 and if3. - there are two ATM network services offered: a1.a2...aN and b1.b2...bN, (where a1.a2...aN is an object identifier used to identify the first service, and b1.b2...bN is the object identifier for the other service. These services may be CIP ARP servers, LECS server, ...) - The first service is available at the ATM address 'a'. - The second service is available at the ATM address 'b'. - The first service can be used by any device connecting to the switch X. - The second service can be used only by devices that connect to interfaces if1 and if3 on switch X. *------------------* *------------------* Iservice a1.a2...aNI Iservice b1.b2...bNI I I I I I ATM address = a I I ATM address = b I *------------------* *------------------* I I ++++++++++++++++++++++++++++++++++++++++++++ + ATM NETWORK + ++++++++++++++++++++++++++++++++++++++++++++ I *-------------* I switch X I *-+----+----+-* I I I Expires XX [Page 20] draft Supplemental ATM Management Objects December 1996 interfaces: if1 if2 if3 The table will contain three entries: - one entry for the "a1.a2...aN", implicitly available to any devices on switch X. - two entries for the "b1.b2...bN" (one for each interface where this service can be explicitly used). The content of the table is: Service Identifier: a1.a2...aN b1.b2...bN b1.b2...bN ATM address: a b b Arbitrary index: m n p Interface: 0 1 3 where m, n and p are arbitrary parameters. When querying the ILMI service registry table, through the ILMI protocol: - the device attached to interface if1 will obtained the address a and b - the device attached to interface if2 will obtained the address a only - the device attached to interface if3 will obtained the address a and b 6.3.15. ILMI Network Prefix Table A table specifying per interface network prefix(es) supplied by the network side of the UNI during ILMI address registration. When no network prefixes are specified for a particular interface, one or more network prefixes based on the switch address(es) may be used for ILMI address registration. Expires XX [Page 21] draft Supplemental ATM Management Objects December 1996 7. Valid Address Sets / Default Address A given ATM UNI interface may have an Address, "ifPhysAddress", to identify the interface. In addition, a given ATM UNI interface may have several other valid addresses which can be used to originate and receive calls. The valid addresses that are used to receive calls are listed in the "ifRcvAddrTable" defined in RFC1573 [6]. ATM interfaces of switches and services do not use the ifRcvAddrTable. Valid addresses to be used by a switch or service are listed in the ATM Interface Administrative Address Table. The ATM Interface Administrative Address Table is not supported by hosts. 8. Configuration of VPLs, VCLs, and Cross-Connects The ATM Managed Objects needed to support the configuration of VPLs, VCLs, and Cross-Connects of the Permanent VPLs and VCLs are defined in the ATM MIB [1]. Cross-Connects of the Switched VPLs and VCLs are defined in this memo. 9. ATM Related Trap Support Two traps are defined to help the network manager to detect the up/down status of the permanent virtual path and links. The current up/down status of the permanent VPL and VCL are indicated by the object atmVplOperStatus and atmVclOperStatus, respectively. Pulling these objects for all the permanent VPLs and VCLs can be a time consuming and resource consuming task. That is why these two traps are defined to provide additinal mechanism to learn the cuurent status of the permanent paths and links. atmPvplChange and atmPvplChange traps are generated just after atmVplOperStatus leaves or enters the up state. In order to avoid the flooding of these two traps in the network due to the link failure, two more objects are added to suppress the traps if necessary. These two objects atmPvplTrapControl and atmPvclTrapControl allow user to disable PVC/PVP traps, send traps if the PVP/PVCs are up or send traps if the PVP/PVCs are down. In addition to these two objects, a new object is provided to the network manager to device a threshold so the Expires XX [Page 22] draft Supplemental ATM Management Objects December 1996 agent will send a trap when the number of up/down connections have hit the threshold value. The threshold object atmTrapThreshold applies to all ATM traps. For example, if the value of this object is set to 15, the atmPvplTrapControl is set to upTrap(1) and the atmPvclTrapControl is set to trapAll(4). An atmPvplChange trap is sent to the trap receiver after 15 PVPs have gone up and an atmPvclChange trap is sent to the trap receiver after 15 PVCs have either gone up or down. The VPI/VCI values and OperStatus included in the trap PDU are the last PVP/PVC up/down event. 10. Definitions ATM2-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, experimental, Counter32, Integer32 FROM SNMPv2-SMI RowStatus, TimeStamp, TEXTUAL-CONVENTION FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF InterfaceIndex, ifIndex FROM IF-MIB atmMIBObjects, atmVclEntry, atmVclVpi, atmVclVci, atmVplEntry, atmVplVpi, atmVplOperStatus, atmVclOperStatus FROM ATM-MIB AtmAddr, AtmSigDescrParamIndex, AtmInterfaceType, AtmIlmiNetworkPrefix, AtmVcIdentifier, AtmVpIdentifier FROM ATM-TC-MIB; Expires XX [Page 23] draft Supplemental ATM Management Objects December 1996 atm2MIB MODULE-IDENTITY LAST-UPDATED "9612051200Z" ORGANIZATION "IETF AToMMIB Working Group" CONTACT-INFO " Faye Ly Postal: 3Com Networks Inc. Santa Clara, CA 95052 US Tel: +1 408 764 6576 Fax: +1 408 495 2599 E-Mail: faye@3com.com Michael Noto Postal: Bell Communications Research 331 Newman Springs Road Red Bank, NJ 07701 US Tel: +1 908 758 5104 Fax: +1 908 758 4177 E-mail: noto@cc.bellcore.com Andrew Smith Postal: Extreme Networks 1601 S. De Anza Blvd, #220 Cupertino, CA 95014 US Tel: +1 408 342 0985 Fax: +1 408 342 0989 E-Mail: ansmith@ix.netcom.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 is a supplement to the ATM-MIB [1]." ::= { experimental XX } atm2MIBObjects OBJECT IDENTIFIER ::= {atm2MIB 1} Expires XX [Page 24] draft Supplemental ATM Management Objects December 1996 atm2MIBTraps OBJECT IDENTIFIER ::= {atm2MIB 2} -- ******** 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. -- This ATM2-MIB Module consists of the following tables: -- 1. atmSvcVcCrossConnectTable -- 2. atmSvcVpCrossConnectTable -- 3. atmSigStatTable -- 4. atmSigSupportTable -- 5. atmSigDescrParamTable -- 6. atmIfAdminAddrTable -- 7. atmVclAddrTable -- 8. atmAddrVclTable -- 9. atmVplStatTable -- 10. atmVplLogicalPortTable -- 11. atmVclStatTable -- 12. atmAal5VclStatTable -- 13. atmVclGenTable -- 14. atmInterfaceExtTable -- 15. atmIlmiSrvcRegTable -- 16. atmIlmiNetworkPrefixTable -- And ATM trap support -- Expires XX [Page 25] draft Supplemental ATM Management Objects December 1996 -- Textual convention for trap control -- This should be moved to the ATM TC MIB AtmTrapControlType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The type of the trap are generated to the trap receiver. noTrap(1) disable the generation of the traps, upTrap(2) will only generate traps if the connection is up and downTrap(3) vice versa. allTrap(4) will generate both up/down traps for the connection." SYNTAX INTEGER { noTrap(1), upTrap(2), downTrap(3), trapAll(4) } -- 1. ATM VPL SVC Cross-Connect Table atmSvcVpCrossConnectTable OBJECT-TYPE SYNTAX SEQUENCE OF AtmSvcVpCrossConnectEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The ATM SVC VP Cross Connect table. A bi- directional VP cross-connect which cross-connects two SVC VPLs is modeled as one entry in this table." ::= { atm2MIBObjects 1 } atmSvcVpCrossConnectEntry OBJECT-TYPE SYNTAX AtmSvcVpCrossConnectEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the ATM SVC VP Cross Connect table. This entry is used to model a bi-directional ATM SVC VP cross-connect which cross-connects two VPLs." INDEX { atmSvcVpCrossConnectIndex, Expires XX [Page 26] draft Supplemental ATM Management Objects December 1996 atmSvcVpCrossConnectLowIfIndex, atmSvcVpCrossConnectLowVpi, atmSvcVpCrossConnectHighIfIndex, atmSvcVpCrossConnectHighVpi } ::= { atmSvcVpCrossConnectTable 1 } AtmSvcVpCrossConnectEntry ::= SEQUENCE { atmSvcVpCrossConnectIndex INTEGER, atmSvcVpCrossConnectLowIfIndex InterfaceIndex, atmSvcVpCrossConnectLowVpi AtmVpIdentifier, atmSvcVpCrossConnectHighIfIndex InterfaceIndex, atmSvcVpCrossConnectHighVpi AtmVpIdentifier, atmSvcVpCrossConnectCreationTime TimeStamp, atmSvcVpCrossConnectRowStatus RowStatus } atmSvcVpCrossConnectIndex OBJECT-TYPE SYNTAX INTEGER (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique value to identify this SVC VP cross-connect." ::= { atmSvcVpCrossConnectEntry 1 } atmSvcVpCrossConnectLowIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The value of this object is equal to MIB II's ifIndex value of the ATM interface port for this SVC VP cross-connect. The term low implies that this ATM interface has the numerically lower ifIndex value than the other ATM interface identified in the same atmSvcVpCrossConnectEntry." ::= { atmSvcVpCrossConnectEntry 2 } atmSvcVpCrossConnectLowVpi OBJECT-TYPE SYNTAX AtmVpIdentifier MAX-ACCESS not-accessible STATUS current DESCRIPTION "The value of this object is equal to the VPI value at the ATM interface Expires XX [Page 27] draft Supplemental ATM Management Objects December 1996 associated with the SVC VP cross-connect that is identified by atmSvcVpCrossConnectLowIfIndex. The VPI value cannot exceed the number supported by the atmInterfaceMaxVpiBits at the low ATM interface port." ::= { atmSvcVpCrossConnectEntry 3 } atmSvcVpCrossConnectHighIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The value of this object is equal to MIB II's ifIndex value of the ATM interface port for this SVC VP cross-connect. The term high implies that this ATM interface has the numerically higher ifIndex value than the other ATM interface identified in the same atmSvcVpCrossConnectEntry." ::= { atmSvcVpCrossConnectEntry 4 } atmSvcVpCrossConnectHighVpi OBJECT-TYPE SYNTAX AtmVpIdentifier MAX-ACCESS not-accessible STATUS current DESCRIPTION "The value of this object is equal to the VPI value at the ATM interface associated with the SVC VP cross-connect that is identified by atmSvcVpCrossConnectHighIfIndex. The VPI value cannot exceed the number supported by the atmInterfaceMaxVpiBits at the high ATM interface port." ::= { atmSvcVpCrossConnectEntry 5 } atmSvcVpCrossConnectCreationTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of MIB II's sysUpTime object at the time this bi-directional SVC VP cross-connect was created. If the current state was entered prior to the last Expires XX [Page 28] draft Supplemental ATM Management Objects December 1996 re-initialization of the agent, then this object contains a zero value." ::= { atmSvcVpCrossConnectEntry 6 } atmSvcVpCrossConnectRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-write STATUS current DESCRIPTION "This object is used to delete rows in the atmSvcVpCrossConnectTable." ::= { atmSvcVpCrossConnectEntry 7 } -- 2. ATM Virtual Channel (VC) Cross Connect Group atmSvcVcCrossConnectTable OBJECT-TYPE SYNTAX SEQUENCE OF AtmSvcVcCrossConnectEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The ATM SVC VC Cross Connect table. A bi- directional SVC VC cross-connect which cross-connects two end points (i.e., VCLs) is modeled as one entry in this table." ::= { atm2MIBObjects 2 } atmSvcVcCrossConnectEntry OBJECT-TYPE SYNTAX AtmSvcVcCrossConnectEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the ATM SVC VC Cross Connect table. This entry is used to model a bi-directional ATM SVC VC cross-connect cross-connecting two end points." INDEX { atmSvcVcCrossConnectIndex, atmSvcVcCrossConnectLowIfIndex, atmSvcVcCrossConnectLowVpi, atmSvcVcCrossConnectLowVci, atmSvcVcCrossConnectHighIfIndex, atmSvcVcCrossConnectHighVpi, atmSvcVcCrossConnectHighVci } Expires XX [Page 29] draft Supplemental ATM Management Objects December 1996 ::= { atmSvcVcCrossConnectTable 1 } AtmSvcVcCrossConnectEntry ::= SEQUENCE { atmSvcVcCrossConnectIndex INTEGER, atmSvcVcCrossConnectLowIfIndex InterfaceIndex, atmSvcVcCrossConnectLowVpi AtmVpIdentifier, atmSvcVcCrossConnectLowVci AtmVcIdentifier, atmSvcVcCrossConnectHighIfIndex InterfaceIndex, atmSvcVcCrossConnectHighVpi AtmVpIdentifier, atmSvcVcCrossConnectHighVci AtmVcIdentifier, atmSvcVcCrossConnectCreationTime TimeStamp, atmSvcVcCrossConnectRowStatus RowStatus } atmSvcVcCrossConnectIndex OBJECT-TYPE SYNTAX INTEGER (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique value to identify this SVC VC cross- connect." ::= { atmSvcVcCrossConnectEntry 1 } atmSvcVcCrossConnectLowIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The value of this object is equal to MIB II's ifIndex value of the ATM interface port for this SVC VC cross-connect. The term low implies that this ATM interface has the numerically lower ifIndex value than the other ATM interface identified in the same atmSvcVcCrossConnectEntry." ::= { atmSvcVcCrossConnectEntry 2 } atmSvcVcCrossConnectLowVpi OBJECT-TYPE SYNTAX AtmVpIdentifier MAX-ACCESS not-accessible STATUS current DESCRIPTION "The value of this object is equal to the VPI value at the ATM interface associated with the SVC VC cross-connect that is Expires XX [Page 30] draft Supplemental ATM Management Objects December 1996 identified by atmSvcVcCrossConnectLowIfIndex. The VPI value cannot exceed the number supported by the atmInterfaceMaxVpiBits at the low ATM interface port." ::= { atmSvcVcCrossConnectEntry 3 } atmSvcVcCrossConnectLowVci OBJECT-TYPE SYNTAX AtmVcIdentifier MAX-ACCESS not-accessible STATUS current DESCRIPTION "The value of this object is equal to the VCI value at the ATM interface associated with this SVC VC cross-connect that is identified by atmSvcVcCrossConnectLowIfIndex. The VCI value cannot exceed the number supported by the atmInterfaceMaxVciBits at the low ATM interface port." ::= { atmSvcVcCrossConnectEntry 4 } atmSvcVcCrossConnectHighIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The value of this object is equal to MIB II's ifIndex value for the ATM interface port for this SVC VC cross-connect. The term high implies that this SVC VC cross-connect that this ATM interface has the numerically higher ifIndex value than the other ATM interface identified in the same atmSvcVcCrossConnectEntry." ::= { atmSvcVcCrossConnectEntry 5 } atmSvcVcCrossConnectHighVpi OBJECT-TYPE SYNTAX AtmVpIdentifier MAX-ACCESS not-accessible STATUS current DESCRIPTION "The value of this object is equal to the VPI value at the ATM interface associated with the SVC VC cross-connect that is identified by atmSvcVcCrossConnectHighIfIndex. The VPI value cannot exceed Expires XX [Page 31] draft Supplemental ATM Management Objects December 1996 the number supported by the atmInterfaceMaxVpiBits at the high ATM interface port." ::= { atmSvcVcCrossConnectEntry 6 } atmSvcVcCrossConnectHighVci OBJECT-TYPE SYNTAX AtmVcIdentifier MAX-ACCESS not-accessible STATUS current DESCRIPTION "The value of this object is equal to the VCI value at the ATM interface associated with the SVC VC cross-connect that is identified by atmSvcVcCrossConnectHighIfIndex. The VCI value cannot exceed the number supported by the atmInterfaceMaxVciBits at the high ATM interface port." ::= { atmSvcVcCrossConnectEntry 7 } atmSvcVcCrossConnectCreationTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of MIB II's sysUpTime object at the time this bi-directional SVC VC cross-connect was created. If the current state was entered prior to the last re-initialization of the agent, then this object contains a zero value." ::= { atmSvcVcCrossConnectEntry 8 } atmSvcVcCrossConnectRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-write STATUS current DESCRIPTION "This object is used to delete rows in the atmSvcVcCrossConnectTable." ::= { atmSvcVcCrossConnectEntry 9 } -- -- 3. ATM Interface Signalling Statistics Table -- Expires XX [Page 32] draft Supplemental ATM Management Objects December 1996 atmSigStatTable OBJECT-TYPE SYNTAX SEQUENCE OF AtmSigStatEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains ATM interface signalling monitoring , one entry per ATM signalling interface." ::= { atm2MIBObjects 3 } atmSigStatEntry OBJECT-TYPE SYNTAX AtmSigStatEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This list contains signalling statistics variables." INDEX { ifIndex } ::= { atmSigStatTable 1} AtmSigStatEntry ::= SEQUENCE { atmSigSSCOPConEvents Counter32, atmSigSSCOPErrdPdus Counter32, atmSigDetectSetupAttempts Counter32, atmSigEmitSetupAttempts Counter32, atmSigDetectUnavailRoutes Counter32, atmSigEmitUnavailRoutes Counter32, atmSigDetectUnavailResrcs Counter32, atmSigEmitUnavailResrcs Counter32, atmSigDetectCldPtyEvents Counter32, atmSigEmitCldPtyEvents Counter32, atmSigDetectMsgErrors Counter32, atmSigEmitMsgErrors Counter32, atmSigDetectClgPtyEvents Counter32, atmSigEmitClgPtyEvents Counter32, atmSigDetectTimerExpireds Counter32, atmSigEmitTimerExpireds Counter32, atmSigDetectRestarts Counter32, atmSigEmitRestarts Counter32, atmSigInEstabls Counter32, atmSigOutEstabls Counter32 } atmSigSSCOPConEvents OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only Expires XX [Page 33] draft Supplemental ATM Management Objects December 1996 STATUS current DESCRIPTION "SSCOP Connection Events Counter. This counter counts the sum of the following errors: 1) SSCOP Connection Disconnect Counter The abnormal occurrence of this event is characterized by the expiry of Timer_NO_RESPONSE. (This event is communicated to the layer management with MAA-ERROR code P. See ITU-T Q.2110 [13].) 2) SSCOP Connection Initiation Failure This condition indicates the inability to establish an SSCOP connection. This event occurs whenever the number of expiries of the connection control timer (Timer_CC) exceeds the MaxCC or upon receipt of a connection reject message BGREJ PDU. (This event is communicated to layer management with MAA-ERROR code O. See ITU-T Q.2110.) 3) SSCOP Connection Re-Establ/Resynch This event occurs upon receipt of a BGN PDU or RESYNC PDU." ::= { atmSigStatEntry 5} atmSigSSCOPErrdPdus OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "SSCOP Errored PDUs Counter. This counter counts the sum of the following errors: 1) Invalid PDUs. These are defined in SSCOP and consist of PDUs with incorrect length (MAA-ERROR code U), undefined PDU type code or not 32-bit aligned. 2) PDUs that result in MAA error codes and are discarded See Errors A-M and Q-T defined in ITU-T Q.2110 [13]." Expires XX [Page 34] draft Supplemental ATM Management Objects December 1996 ::= { atmSigStatEntry 6 } atmSigDetectSetupAttempts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Call Setup Attempts Counter. This counter counts the number of call setup attempts(both successful and unsuccessful) detected on this interface." ::= { atmSigStatEntry 7 } atmSigEmitSetupAttempts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Call Setup Attempts Counter. This counter counts the number of call setup attempts(both successful and unsuccessful) transmitted on this interface." ::= { atmSigStatEntry 8 } atmSigDetectUnavailRoutes OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of Route Unavailability detected on this interface. This counter is incremented when a RELEASE, RELEASE COMPLETE (only when not preceded by a RELEASE mesg for the same call), ADD PARTY REJECT, or STATUS message that contains one of the following cause code values is received (Note: These cause values apply to both UNI3.0 and UNI3.1): Expires XX [Page 35] draft Supplemental ATM Management Objects December 1996 Cause Value Meaning 1 unallocated (unassigned) number 2 no route to specified transit network 3 no route to destination 88 incompatible destination NOTE: For this counter, RELEASE COMPLETE messages that are a reply to a previous RELEASE message and contain the same cause value, are redundant (for counting purposes) and should not be counted." ::= { atmSigStatEntry 9 } atmSigEmitUnavailRoutes OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of Route Unavailability transmitted from this interface. This counter is incremented when a RELEASE, RELEASE COMPLETE (only when not preceded by a RELEASE mesg for the same call), ADD PARTY REJECT, or STATUS message that contains one of the following cause code values is transmitted (Note: These cause values apply to both UNI3.0 and UNI3.1): Expires XX [Page 36] draft Supplemental ATM Management Objects December 1996 Cause Value Meaning 1 unallocated (unassigned) number 2 no route to specified transit network 3 no route to destination NOTE: For this counter, RELEASE COMPLETE messages that are a reply to a previous RELEASE message and contain the same cause value, are redundant (for counting purposes) and should not be counted." ::= { atmSigStatEntry 10 } atmSigDetectUnavailResrcs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of Resource Unavailability detected on this interfrace. This counter is incremented when a RELEASE, RELEASE COMPLETE (only when not preceded by a RELEASE mesg for the same call), ADD PARTY REJECT, or STATUS message that contains one of the following cause code values is received (Note: These cause values apply to both UNI3.0 and UNI3.1 unless otherwise stated): Cause Value Meaning 35 requested VPCI/VCI not available 37 user cell rate not available (UNI3.1 only) 38 network out of order 41 temporary failure 45 no VPCI/VCI available 47 resource unavailable, unspecified 49 Quality of Service unavailable 51 user cell rate not available (UNI3.0 only) 58 bearer capability not presently available 63 Service or option not available, unspecified 92 too many pending add party requests Expires XX [Page 37] draft Supplemental ATM Management Objects December 1996 NOTE: For this counter, RELEASE COMPLETE messages that are a reply to a previous RELEASE message and contain the same cause value, are redundant (for counting purposes) and should not be counted." ::= { atmSigStatEntry 11 } atmSigEmitUnavailResrcs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of Resource Unavailability transmitted from this interfrace. This counter is incremented when a RELEASE, RELEASE COMPLETE (only when not preceded by a RELEASE mesg for the same call), ADD PARTY REJECT, or STATUS message that contains one of the following cause code values is transmitted (Note: These cause values apply to both UNI3.0 and UNI3.1 unless otherwise stated): Cause Value Meaning 35 requested VPCI/VCI not available 37 user cell rate not available (UNI3.1 only) 38 network out of order 41 temporary failure 45 no VPCI/VCI available 47 resource unavailable, unspecified 49 Quality of Service unavailable 51 user cell rate not available (UNI3.0 only) 58 bearer capability not presently available 63 Service or option not available, unspecified 92 too many pending add party requests NOTE: For this counter, RELEASE COMPLETE messages that are a reply to a previous RELEASE message and contain the same cause value, are redundant (for counting purposes) and should not Expires XX [Page 38] draft Supplemental ATM Management Objects December 1996 be counted." ::= { atmSigStatEntry 12 } atmSigDetectCldPtyEvents OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of Called Party Responsible For Unsuccessful Call detected on this interface. This counter is incremented when a RELEASE, RELEASE COMPLETE (only when not preceded by a RELEASE mesg for the same call), ADD PARTY REJECT, or STATUS message that contains one of the following cause code values is received (Note: These cause values apply to both UNI3.0 and UNI3.1): Cause Value Meaning 17 user busy 18 no user responding 21 call rejected 22 number changed 23 user rejects all calls with calling line id restriction (CLIR) 27 destination out of order 31 normal, unspecified 88 incompatible destination NOTE: For this counter, RELEASE COMPLETE messages that are a reply to a previous RELEASE message and contain the same cause value, are redundant (for counting purposes) and should not be counted. Note: Cause Value #30 'response to STATUS ENQUIRY' was not included in this memo since it did not apply to a hard failure." ::= { atmSigStatEntry 13 } atmSigEmitCldPtyEvents OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current Expires XX [Page 39] draft Supplemental ATM Management Objects December 1996 DESCRIPTION "Number of Called Party Responsible For Unsuccessful Call transmitted from this interface. This counter is incremented when a RELEASE, RELEASE COMPLETE (only when not preceded by a RELEASE mesg for the same call), ADD PARTY REJECT, or STATUS message that contains one of the following cause code values is transmitted (Note: These cause values apply to both UNI3.0 and UNI3.1): Cause Value Meaning 17 user busy 18 no user responding 21 call rejected 22 number changed 23 user rejects all calls with calling line id restriction (CLIR) 27 destination out of order 31 normal, unspecified 88 incompatible destination NOTE: For this counter, RELEASE COMPLETE messages that are a reply to a previous RELEASE message and contain the same cause value, are redundant (for counting purposes) and should not be counted. Note: Cause Value #30 'response to STATUS ENQUIRY' was not included in this memo since it did not apply to a hard failure." ::= { atmSigStatEntry 14 } atmSigDetectMsgErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of Incorrect Messages detected on this interface. The Incorrect Messages Counter reflects any sort of incorrect information in a message. This includes: - RELEASE, RELEASE COMPLETE, ADD PARTY REJECT, Expires XX [Page 40] draft Supplemental ATM Management Objects December 1996 and STATUS messages transmitted, that contain any of the Cause values listed below. - Ignored messages. These messages are dropped because the message was so damaged that it could not be further processed. A list of dropped messages is compiled below: 1. Message with invalid protocol discriminator 2. Message with errors in the call reference I.E. - Bits 5-8 of the first octet not equal to '0000' - Bits 1-4 of the first octet indicating a length other than 3 octets - RELEASE COMPLETE message received with a call reference that does not relate to a call active or in progress - SETUP message received with call reference flag incorrectly set to 1 - SETUP message received with a call reference for a call that is already active or in progress. 3. Message too short The following cause values are monitored by this counter (Note: These cause values apply to both UNI3.0 and UNI3.1 unless otherwise stated): Cause Value Meaning 10 VPCI/VCI unacceptable (UNI3.0 only) 36 VPCI/VCI assignment failure (UNI3.1 only) 81 invalid call reference value 82 identified channel does not exist 89 invalid endpoint reference 96 mandatory information element is missing 97 message type non-existent or not implemented 99 information element non-existent or not implemented 100 invalid information element contents Expires XX [Page 41] draft Supplemental ATM Management Objects December 1996 101 message not compatible with call state 104 incorrect message length 111 protocol error, unspecified NOTE: For this counter, RELEASE COMPLETE messages that are a reply to a previous RELEASE message and contain the same cause value, are redundant (for counting purposes) and should not be counted." ::= { atmSigStatEntry 15 } atmSigEmitMsgErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of Incorrect Messages detected on this interface. The Incorrect Messages Counter reflects any sort of incorrect information in a message. This includes: - RELEASE, RELEASE COMPLETE, ADD PARTY REJECT, and STATUS messages transmitted or received, that contain any of the Cause values listed below. - Ignored messages. These messages are dropped because the message was so damaged that it could not be further processed. A list of dropped messages is compiled below: 1. Message with invalid protocol discriminator 2. Message with errors in the call reference I.E. - Bits 5-8 of the first octet not equal to '0000' - Bits 1-4 of the first octet indicating a length other than 3 octets - RELEASE COMPLETE message received with a call reference that does not relate to a call active or in progress - SETUP message received with call reference flag incorrectly set to 1 Expires XX [Page 42] draft Supplemental ATM Management Objects December 1996 - SETUP message received with a call reference for a call that is already active or in progress. 3. Message too short The following cause values are monitored by this counter (Note: These cause values apply to both UNI3.0 and UNI3.1 unless otherwise stated): Cause Value Meaning 10 VPCI/VCI unacceptable (UNI3.0 only) 36 VPCI/VCI assignment failure (UNI3.1 only) 81 invalid call reference value 82 identified channel does not exist 89 invalid endpoint reference 96 mandatory information element is missing 97 message type non-existent or not implemented 99 information element non-existent or not implemented 100 invalid information element contents 101 message not compatible with call state 104 incorrect message length 111 protocol error, unspecified NOTE: For this counter, RELEASE COMPLETE messages that are a reply to a previous RELEASE message and contain the same cause value, are redundant (for counting purposes) and should not be counted." ::= { atmSigStatEntry 16 } atmSigDetectClgPtyEvents OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of Calling Party Events detected on this interface. This counter monitors error events that occur due to the originating user doing something wrong. This counter is incremented when a RELEASE, Expires XX [Page 43] draft Supplemental ATM Management Objects December 1996 RELEASE COMPLETE (only when not preceded by a RELEASE mesg for the same call), ADD PARTY REJECT, or STATUS message that contains one of the following cause code values is received (Note: These cause values apply to both UNI3.0 and UNI3.1): Cause Value Meaning 28 invalid number format (address incomplete) 43 access information discarded 57 bearer capability not authorized 65 bearer capability not implemented 73 unsupported combination of traffic parameters 78 AAL parameters cannot be supported (UNI3.1 only) 91 invalid transit network selection 93 AAL parameters cannot be supported (UNI3.0 only) NOTE: For this counter, RELEASE COMPLETE messages that are a reply to a previous RELEASE message and contain the same cause value, are redundant (for counting purposes) and should not be counted." ::= { atmSigStatEntry 17 } atmSigEmitClgPtyEvents OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of Calling Party Events transmitted from this interface. This counter monitors error events that occur due to the originating user doing something wrong. This counter is incremented when a RELEASE, RELEASE COMPLETE (only when not preceded by a RELEASE mesg for the same call), ADD PARTY REJECT, or STATUS message that contains one of the following cause code values is transmitted (Note: These cause values apply to both UNI3.0 and UNI3.1): Cause Value Meaning Expires XX [Page 44] draft Supplemental ATM Management Objects December 1996 28 invalid number format (address incomplete) 43 access information discarded 57 bearer capability not authorized 65 bearer capability not implemented 73 unsupported combination of traffic parameters 78 AAL parameters cannot be supported (UNI3.1 only) 91 invalid transit network selection 93 AAL parameters cannot be supported (UNI3.0 only) NOTE: For this counter, RELEASE COMPLETE messages that are a reply to a previous RELEASE message and contain the same cause value, are redundant (for counting purposes) and should not be counted." ::= { atmSigStatEntry 18 } atmSigDetectTimerExpireds OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of Timer Expiries detected on this interface. The Timer Expiries Counter provides a count of network timer expiries, and to some extent, host or switch timer expiries. The conditions for incrementing this counter are: - Expiry of any network timer - Receipt of a RELEASE or RELEASE COMPLETE message with Cause #102, 'recovery on timer expiry'. NOTE: For this counter, RELEASE COMPLETE messages that are a reply to a previous RELEASE message and contain the same cause value, are redundant (for counting purposes) and should not be counted." ::= { atmSigStatEntry 19 } atmSigEmitTimerExpireds OBJECT-TYPE SYNTAX Counter32 Expires XX [Page 45] draft Supplemental ATM Management Objects December 1996 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of Timer Expiries transmitted from this interface. The Timer Expiries Counter provides a count of network timer expiries, and to some extent, host or switch timer expiries. The conditions for incrementing this counter are: - Expiry of any network timer - Receipt of a RELEASE or RELEASE COMPLETE message with Cause #102, 'recovery on timer expiry'. NOTE: For this counter, RELEASE COMPLETE messages that are a reply to a previous RELEASE message and contain the same cause value, are redundant (for counting purposes) and should not be counted." ::= { atmSigStatEntry 20 } atmSigDetectRestarts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of Restart Activity errors detected on this interface. The Restart Activity Counter provides a count of host, switch, or network restart activity. This counter is incremented when receiving a RESTART message." ::= { atmSigStatEntry 21 } atmSigEmitRestarts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of Restart Activity errors transmitted from this interface. The Restart Activity Counter provides a count of host, switch, or network restart activity. This counter is incremented when transmitting a RESTART message." ::= { atmSigStatEntry 22 } Expires XX [Page 46] draft Supplemental ATM Management Objects December 1996 atmSigInEstabls OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of SVC VCCs established at this signalling entity for incoming connections." ::= { atmSigStatEntry 23 } atmSigOutEstabls OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of SVC VCCs established at this signalling entity for outgoing connections." ::= { atmSigStatEntry 24 } Expires XX [Page 47] draft Supplemental ATM Management Objects December 1996 -- 4. ATM Interface Signalling Support Table -- This table provides information to support -- the signalling process which is used to establish -- ATM Switched Virtual Connections (SVCs). atmSigSupportTable OBJECT-TYPE SYNTAX SEQUENCE OF AtmSigSupportEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains ATM local interface configuration parameters, one entry per ATM signalling interface." ::= { atm2MIBObjects 4 } atmSigSupportEntry OBJECT-TYPE SYNTAX AtmSigSupportEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This list contains signalling configuration parameters and state variables." INDEX { ifIndex } ::= { atmSigSupportTable 1} AtmSigSupportEntry ::= SEQUENCE { atmSigSupportClgPtyNumDel INTEGER, atmSigSupportClgPtySubAddr INTEGER, atmSigSupportCldPtySubAddr INTEGER, atmSigSupportHiLyrInfo INTEGER, atmSigSupportLoLyrInfo INTEGER, atmSigSupportBlliRepeatInd INTEGER, atmSigSupportAALInfo INTEGER, atmSigSupportPrefCarrier OCTET STRING } atmSigSupportClgPtyNumDel OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "This object indicates whether the Calling Party Number Information Element is transferred to the called party address. The value of this object can be: - enabled(1) This Information Element is transferred Expires XX [Page 48] draft Supplemental ATM Management Objects December 1996 to the called party - disabled(2) This Information Element is NOT transferred to the called party." ::= { atmSigSupportEntry 1 } atmSigSupportClgPtySubAddr OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "This object indicates whether to accept and transfer the Calling Party Subaddress Information Element from the calling party to the called party. Calling party subaddress information shall only be transferred to the called party if calling party number delivery is enabled (i.e., atmSigSupportClgPtyNumDel = 'enabled(1)'. The value of this object can be: - enabled(1) This Information Element is transferred to the called party - disabled(2) This Information Element is NOT transferred to the called party." ::= { atmSigSupportEntry 2 } atmSigSupportCldPtySubAddr OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "This object indicates whether to accept, transfer, and deliver the Called Party Subaddress Information Element from the calling party to the called party. The value of this object can be: - enabled(1) This Information Element is transferred to the called party - disabled(2) This Information Element is NOT transferred to the called party." ::= { atmSigSupportEntry 3 } atmSigSupportHiLyrInfo OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2) } MAX-ACCESS read-write Expires XX [Page 49] draft Supplemental ATM Management Objects December 1996 STATUS current DESCRIPTION "This object indicates whether to accept, transfer, and deliver the Broadband High Layer Information Element from the calling party to the called party. The value of this object can be: - enabled(1) This Information Element is transferred to the called party - disabled(2) This Information Element is NOT transferred to the called party." ::= { atmSigSupportEntry 4 } atmSigSupportLoLyrInfo OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "This object indicates whether to accept, transfer, and deliver the Broadband Low Layer Information Element from the calling party to the called party. The value of this object can be: - enabled(1) This Information Element is transferred to the called party - disabled(2) This Information Element is NOT transferred to the called party." ::= { atmSigSupportEntry 5 } atmSigSupportBlliRepeatInd OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "This object indicates whether to accept, transfer, and deliver the Broadband Repeat Indicator with two or three instances of the Broadband Low Layer Information Element for low layer information selection from the calling party to the called party. This object shall only be transferred if atmSigSupportLoLyrInfo = 'enabled(1)'. The value of this object can be: - enabled(1) This Information Element is transferred to the called party Expires XX [Page 50] draft Supplemental ATM Management Objects December 1996 - disabled(2) This Information Element is NOT transferred to the called party." ::= { atmSigSupportEntry 6 } atmSigSupportAALInfo OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "This object indicates whether to accept, transfer, and deliver the ATM Adaptation Layer Parameters Information Element from the calling party to the called party. The value of this object can be: - enabled(1) This Information Element is transferred to the called party - disabled(2) This Information Element is NOT transferred to the called party." ::= { atmSigSupportEntry 7 } atmSigSupportPrefCarrier OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-write STATUS current DESCRIPTION "This parameter identifies the carrier to which intercarrier calls originated from this interface are routed when transit network selection information is not provided by the calling party. If a Carrier Identification Code (CIC) is used the parameter shall contain the CIC. For three-digit CICs, the first octet shall be '0' and the CIC is contained in the three following octets. If the preferred carrier feature is not supported the value is a zero-length string." ::= { atmSigSupportEntry 8 } -- 5. ATM Signalling Descriptor Parameter Table atmSigDescrParamTable OBJECT-TYPE SYNTAX SEQUENCE OF AtmSigDescrParamEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION Expires XX [Page 51] draft Supplemental ATM Management Objects December 1996 "A table contains signalling capabilities of VCLs except the Traffic Descriptor. Traffic descriptors are described in the atmTrafficDescrParamTable." REFERENCE "ATM Forum's ATM User-Network Interface Specification, Version 3.0, Section 5.4.5 Variable Length Information Elements." ::= { atm2MIBObjects 5 } atmSigDescrParamEntry OBJECT-TYPE SYNTAX AtmSigDescrParamEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry in this table represents a set of signalling capabilities that can be applied to a VCL. There is no requirement for unique entries, except that the index must be unique. Objects atmSigDescrParamRowStatus is required during creation." INDEX { atmSigDescrParamIndex } ::= { atmSigDescrParamTable 1 } AtmSigDescrParamEntry ::= SEQUENCE { atmSigDescrParamIndex AtmSigDescrParamIndex, atmSigDescrParamAalType INTEGER, atmSigDescrParamAalSscsType INTEGER, atmSigDescrParamBhliType INTEGER, atmSigDescrParamBhliInfo OCTET STRING, atmSigDescrParamBbcConnConf INTEGER, atmSigDescrParamBlliLayer2 INTEGER, atmSigDescrParamBlliLayer3 INTEGER, atmSigDescrParamBlliPktSize INTEGER, atmSigDescrParamBlliSnapId INTEGER, atmSigDescrParamBlliOuiPid OCTET STRING, atmSigDescrParamRowStatus RowStatus } atmSigDescrParamIndex OBJECT-TYPE SYNTAX AtmSigDescrParamIndex MAX-ACCESS not-accessible STATUS current Expires XX [Page 52] draft Supplemental ATM Management Objects December 1996 DESCRIPTION "The value of this object is used by the atmVclExtTable to identify a row in this table." ::= { atmSigDescrParamEntry 1 } atmSigDescrParamAalType OBJECT-TYPE SYNTAX INTEGER { other(1), -- not defined aal1(2), -- AAL type 1 aal34(3), -- AAL type 3/4 aal5(4), -- AAL type 5 userDefined(5) -- User-Defined AAL } MAX-ACCESS read-create STATUS current DESCRIPTION "The AAL type. The value of this object is set to other(1) when not defined." DEFVAL { other } ::= { atmSigDescrParamEntry 2 } atmSigDescrParamAalSscsType OBJECT-TYPE SYNTAX INTEGER { other(1), -- other, or not used assured(2), -- Data SSCS based on SSCOP -- assured operation nonassured(3), -- Data SSCS based on SSCOP -- non-assured operation frameRelay(4), -- frame relay SSCS null(5) -- null } MAX-ACCESS read-create STATUS current DESCRIPTION "The SSCS type used by this entry." DEFVAL { other } ::= { atmSigDescrParamEntry 3 } atmSigDescrParamBhliType OBJECT-TYPE SYNTAX INTEGER { other(1), -- not defined iso(2), -- ISO user(3), -- User specific hiProfile(4), -- Higher layer profile Expires XX [Page 53] draft Supplemental ATM Management Objects December 1996 -- this enum applicable to -- UNI 3.0 only vendorSpecific(5) -- Vender specific -- application identifier } MAX-ACCESS read-create STATUS current DESCRIPTION "The Broadband high layer type." DEFVAL { other } ::= { atmSigDescrParamEntry 4 } atmSigDescrParamBhliInfo OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..7)) MAX-ACCESS read-create STATUS current DESCRIPTION "The Broadband high layer information. When atmSigDescrParamBhliType is set to iso(2), the value of this object is a zero length string. When atmSigDescrParamBhliType is set to hiProfile(4), the value of this object is a length of 4 octet string containing user to user profile identifier. When atmSigDescrParamBhliType is set to vendorSpecific(4), the value of this object is a length of 7 octet string. The most significant 3 octets consist of a globally- administered OUI, the least significant 4 octets are the vender administered application OUI." DEFVAL { ''H } ::= { atmSigDescrParamEntry 5 } atmSigDescrParamBbcConnConf OBJECT-TYPE SYNTAX INTEGER { ptp(1), -- point-to-point ptmp(2) -- point-to-multipoint } MAX-ACCESS read-create STATUS current DESCRIPTION "The Broadband bearer capability user plane connection configuration parameter." ::= { atmSigDescrParamEntry 6 } Expires XX [Page 54] draft Supplemental ATM Management Objects December 1996 atmSigDescrParamBlliLayer2 OBJECT-TYPE SYNTAX INTEGER { other(1), -- not specified iso1745(2), -- Basic mode ISO 1745 q921(3), -- CCITT Recommendation Q.921 x25linklayer(4), -- CCITT Recommendation X.25 -- Link Layer x25multilink(5), -- CCITT Recommendation X.25 -- Multilink lapb(6), -- Extended LAPB; for half -- duplex operation hdlcArm(7), -- HDLC ARM (ISO 4335) hdlcNrm(8), -- HDLC NRM (ISO 4335) hdlcAbm(9), -- HDLC ABM (ISO 4335) iso88022(10), -- LAN logical link control -- (ISO 8802/2) x75slp(11), -- CCITT Recommendation X.75, -- single link -- procedure (SLP) q922(12), -- CCITT Recommendation Q.922 userDef(13), -- User specified iso7776(14) -- ISO 7776 DTE-DTE operation } MAX-ACCESS read-create STATUS current DESCRIPTION "The Broadband low layer information, protocol type of layer 2. The value of this object is other(1) if layer 2 protocol is not used." DEFVAL { other } ::= { atmSigDescrParamEntry 7 } atmSigDescrParamBlliLayer3 OBJECT-TYPE SYNTAX INTEGER { other(1), -- not specified x25pkt(2), -- CCITT Recommendation X.25 -- packet layer isoiec8208(3), -- ISO/IEC 8208 (X.25 packet -- level protocol for data -- terminal equipment) x223iso8878(4), -- X.223/ISO 8878 isoiec8473(5), -- ISO/IEC 8473 OSI -- connectionless -- mode protocol Expires XX [Page 55] draft Supplemental ATM Management Objects December 1996 t70(6), -- CCITT Recommendation T.70 -- minimum -- network layer tr9577(7), -- ISO/IEC TR 9577 Protocol -- Identification in the -- network layer userDef(8) -- user specified } MAX-ACCESS read-create STATUS current DESCRIPTION "The Broadband low layer information, protocol type of layer 3. The value of this object is other(1) if layer 3 protocol is not used." DEFVAL { other } ::= { atmSigDescrParamEntry 8 } atmSigDescrParamBlliPktSize OBJECT-TYPE SYNTAX INTEGER { other(1), -- not used s16(2), -- 16 octets s32(3), -- 32 octets s64(4), -- 64 octets s128(5), -- 128 octets s256(6), -- 256 octets s512(7), -- 512 octets s1024(8), -- 1028 octets s2048(9), -- 2048 octets s4096(10) -- 4096 octets } MAX-ACCESS read-create STATUS current DESCRIPTION "The default packet size defined in B-LLI." DEFVAL { other } ::= { atmSigDescrParamEntry 9 } atmSigDescrParamBlliSnapId OBJECT-TYPE SYNTAX INTEGER { other(1), -- not used true(2), -- SNAP ID is 1 false(3) -- SNAP ID is 0 } MAX-ACCESS read-create Expires XX [Page 56] draft Supplemental ATM Management Objects December 1996 STATUS current DESCRIPTION "The SNAP ID used for Broadband low layer protocol layer 3. The value of this object is other(1) if atmSigDescrParamBlliLayer3 is set to other(1)." DEFVAL { other } ::= { atmSigDescrParamEntry 10 } atmSigDescrParamBlliOuiPid OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..5)) MAX-ACCESS read-create STATUS current DESCRIPTION "The OUI/PID encoding for Broadband low layer protocol layer 3. The value of this object is a zero length string if atmSigDescrParamBlliLayer3 is set to none(1). When used, it is always 5 octets with the most significant octet as the OUI Octet 1 and the least significant octet as the PID Octet 2." DEFVAL { ''H } ::= { atmSigDescrParamEntry 11 } atmSigDescrParamRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object is used to create and delete rows in the atmSigDescrParamTable. Writable values are: -'createAndWait' which allows manager to create an entry first and fill in the parameters later. -'active' which allows manager to set the entry to be available to users. -'destroy' which allows manager to delete an entry from this table. Readable values are: -'createAndWait' which means the entry is created but not available to be used. -'active' means it is active and ready to be used by agent or manager." ::= { atmSigDescrParamEntry 12 } Expires XX [Page 57] draft Supplemental ATM Management Objects December 1996 -- -- 6. ATM Interface Administrative Address Table -- atmIfAdminAddrTable OBJECT-TYPE SYNTAX SEQUENCE OF AtmIfAdminAddrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains an address list on a per interface basis. This table only applies to switches or networks and only for interfaces that have more than one address assigned." ::= { atm2MIBObjects 6 } atmIfAdminAddrEntry OBJECT-TYPE SYNTAX AtmIfAdminAddrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the atmIfAdminAddrTable." INDEX { ifIndex, atmIfAdminAddrAddress } ::= { atmIfAdminAddrTable 1} AtmIfAdminAddrEntry ::= SEQUENCE { atmIfAdminAddrAddress AtmAddr, atmIfAdminAddrAddressSource INTEGER, atmIfAdminAddrRowStatus RowStatus } atmIfAdminAddrAddress OBJECT-TYPE SYNTAX AtmAddr MAX-ACCESS not-accessible STATUS current DESCRIPTION "A valid address for a given switch or network interface." ::= { atmIfAdminAddrEntry 1} atmIfAdminAddrAddressSource OBJECT-TYPE SYNTAX INTEGER { other(1), static(2), dynamic(3) Expires XX [Page 58] draft Supplemental ATM Management Objects December 1996 } MAX-ACCESS read-only STATUS current DESCRIPTION "The type of address source for a given ATM Address. i.e. Value dynamic(3) is used when ILMI is used." ::= { atmIfAdminAddrEntry 2} atmIfAdminAddrRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object is used to create and delete rows in the atmIfAdminAddrTable." ::= { atmIfAdminAddrEntry 3} -- 7. ATM VPI/VCI to Address Mapping Table atmVclAddrTable OBJECT-TYPE SYNTAX SEQUENCE OF AtmVclAddrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table provides a mapping between the atmVclTable and the ATM called party/calling party address. This table can be used to retrieve the calling party and called party ATM address pair for a given Vcl. Note that there can be more than one pair of calling party and called party ATM addresses for a VCL in a point to multi-point call." ::= { atm2MIBObjects 7 } atmVclAddrEntry OBJECT-TYPE SYNTAX AtmVclAddrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry in this table represents a binding between a VCL and an ATM address associated with this call. This ATM address can be either the called party address or the calling party address. Expires XX [Page 59] draft Supplemental ATM Management Objects December 1996 There can be more than one pair of calling/called party ATM addresses associated with the VCL entry for point to multi-point calls. Objects atmVclAddrAddr, atmVclAddrType, and atmVclAddrRowStatus are required during row creation." INDEX { ifIndex, atmVclVpi, atmVclVci, atmVclAddrAddr } ::= { atmVclAddrTable 1 } AtmVclAddrEntry ::= SEQUENCE { atmVclAddrAddr AtmAddr, atmVclAddrType INTEGER, atmVclAddrRowStatus RowStatus } atmVclAddrAddr OBJECT-TYPE SYNTAX AtmAddr MAX-ACCESS not-accessible STATUS current DESCRIPTION "An ATM address on one end of the VCL. For SVCs, the agent supplies the value of this object at creation time. For PVCs, manager can supply the value of this object during or after the PVC creation." ::= { atmVclAddrEntry 1 } atmVclAddrType OBJECT-TYPE SYNTAX INTEGER { callingParty(1), calledParty(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "The type of ATM Address represented by the object atmVclAddrAddr. Choices are either the calling party ATM address or the called party ATM address." ::= { atmVclAddrEntry 2 } atmVclAddrRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create Expires XX [Page 60] draft Supplemental ATM Management Objects December 1996 STATUS current DESCRIPTION "This object is used to create or destroy an entry from this table." ::= { atmVclAddrEntry 3 } -- 8. ATM Address to VPI/VCI Mapping Table -- This table provides an alternative way to access -- a row in the atmVclAddrTable by using -- an ATM address as an index, instead of -- the ifIndex atmAddrVclTable OBJECT-TYPE SYNTAX SEQUENCE OF AtmAddrVclEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table provides an alternative way to retrieve the atmVclTable. This table can be used to retrieve the indexing to the atmVclTable by an ATM address." ::= { atm2MIBObjects 8 } atmAddrVclEntry OBJECT-TYPE SYNTAX AtmAddrVclEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry in this table represents an entry in the atmVclTable of the ATM MIB [1] by it's ATM address. The ATM address is either the calling or called party ATM address of the call. Entries in this table are read only. They show up when entries are created in the atmVclAddrTable." INDEX { atmVclAddrAddr, atmAddrVclAtmIfIndex, atmAddrVclVpi, atmAddrVclVci } ::= { atmAddrVclTable 1 } AtmAddrVclEntry ::= SEQUENCE { atmAddrVclAtmIfIndex InterfaceIndex, atmAddrVclVpi AtmVpIdentifier, atmAddrVclVci AtmVcIdentifier, Expires XX [Page 61] draft Supplemental ATM Management Objects December 1996 atmAddrVclAddrType INTEGER } atmAddrVclAtmIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The interface index of the ATM interface where this VCL pertains to. This object combined with the atmAddrVclVpi and atmAddrVclVci objects serves as an index to the atmVclTable." ::= { atmAddrVclEntry 1 } atmAddrVclVpi OBJECT-TYPE SYNTAX AtmVpIdentifier MAX-ACCESS not-accessible STATUS current DESCRIPTION "The VPI value of the VCL. This object combined with the atmAddrVclAtmIfIndex and atmAddrVclVci objects serves as an index to the atmVclTable." ::= { atmAddrVclEntry 2 } atmAddrVclVci OBJECT-TYPE SYNTAX AtmVcIdentifier MAX-ACCESS not-accessible STATUS current DESCRIPTION "The VCI value of the VCL. This object combined with the atmAddrVclAtmIfIndex and atmAddrVclVpi objects serves as an index to the atmVclTable." ::= { atmAddrVclEntry 3 } atmAddrVclAddrType OBJECT-TYPE SYNTAX INTEGER { callingParty(1), calledParty(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "The type of ATM Address represented by the object atmVclAddrAddr. Choices are either calling party address or called party address." ::= { atmAddrVclEntry 4 } Expires XX [Page 62] draft Supplemental ATM Management Objects December 1996 -- 9. ATM VPL Statistics Table atmVplStatTable OBJECT-TYPE SYNTAX SEQUENCE OF AtmVplStatEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains all statistic counters per VPL. It is used to monitor the usage of the VPL in terms of incoming cells and outgoing cells." ::= { atm2MIBObjects 9 } atmVplStatEntry OBJECT-TYPE SYNTAX AtmVplStatEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry in this table represents a VPL." INDEX { ifIndex, atmVplVpi } ::= { atmVplStatTable 1 } AtmVplStatEntry ::= SEQUENCE { atmVplStatTotalCellIns Counter32, atmVplStatClp0CellIns Counter32, atmVplStatTotalDiscards Counter32, atmVplStatClp0Discards Counter32, atmVplStatTotalCellOuts Counter32, atmVplStatClp0CellOuts Counter32, atmVplStatTaggedOuts Counter32 } atmVplStatTotalCellIns OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of valid ATM cells received by this VPL including both CLP=0 and CLP=1 cells. The cells are counted prior to the application of the traffic policing." ::= { atmVplStatEntry 1 } atmVplStatClp0CellIns OBJECT-TYPE Expires XX [Page 63] draft Supplemental ATM Management Objects December 1996 SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of valid ATM cells received by this VPL with CLP=0. The cells are counted prior to the application of the traffic policing." ::= { atmVplStatEntry 2 } atmVplStatTotalDiscards OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of valid ATM cells discarded by the traffic policing entity. This includes cells orginally received with CLP=0 and CLP=1." ::= { atmVplStatEntry 3 } atmVplStatClp0Discards OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of valid ATM cells received with CLP=0 an discarded by the traffic policing entity." ::= { atmVplStatEntry 4 } atmVplStatTotalCellOuts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of valid ATM cells transmitted by this VPL. This includes both CLP=0 and CLP=1 cells." ::= { atmVplStatEntry 5 } atmVplStatClp0CellOuts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION Expires XX [Page 64] draft Supplemental ATM Management Objects December 1996 "The total number of valid ATM cells transmitted with CLP=0 by this VPL." ::= { atmVplStatEntry 6 } atmVplStatTaggedOuts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of valid ATM cells tagged by the traffic policing entity from CLP=0 to CLP=1 and transmitted by this VPL." ::= { atmVplStatEntry 7 } -- 10. ATM Logical Port Configuration Table atmVplLogicalPortTable OBJECT-TYPE SYNTAX SEQUENCE OF AtmVplLogicalPortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Indicates whether the VPL is an ATM Logical Port interface (ifType=80)." ::= { atm2MIBObjects 10 } atmVplLogicalPortEntry OBJECT-TYPE SYNTAX AtmVplLogicalPortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry with information about the ATM Logical Port interface." AUGMENTS { atmVplEntry } ::= { atmVplLogicalPortTable 1 } AtmVplLogicalPortEntry ::= SEQUENCE { atmVplLogicalPortDef INTEGER, atmVplLogicalPortIndex InterfaceIndex Expires XX [Page 65] draft Supplemental ATM Management Objects December 1996 } atmVplLogicalPortDef OBJECT-TYPE SYNTAX INTEGER { notLogicalIf(1), isLogicalIf(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates whether the VPC at this VPL interface is an ATM Logical Port interface." DEFVAL { notLogicalIf } ::= { atmVplLogicalPortEntry 1 } atmVplLogicalPortIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "The ifTable index of the ATM logical port interface associated with this VPL. Only valid if the value of atmVplLogicalPortDef is isLogicalIf, and the VPL row is active." ::= { atmVplLogicalPortEntry 2 } Expires XX [Page 66] draft Supplemental ATM Management Objects December 1996 -- 11. ATM VCL Statistics Table atmVclStatTable OBJECT-TYPE SYNTAX SEQUENCE OF AtmVclStatEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains all statistic counters per VCL. It is used to monitor the usage of the VCL in terms of incoming cells and outgoing cells." ::= { atm2MIBObjects 11 } atmVclStatEntry OBJECT-TYPE SYNTAX AtmVclStatEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry in this table represents a VCL." INDEX { ifIndex, atmVclVpi, atmVclVci } ::= { atmVclStatTable 1 } AtmVclStatEntry ::= SEQUENCE { atmVclStatTotalCellIns Counter32, atmVclStatClp0CellIns Counter32, atmVclStatTotalDiscards Counter32, atmVclStatClp0Discards Counter32, atmVclStatTotalCellOuts Counter32, atmVclStatClp0CellOuts Counter32, atmVclStatTaggedOuts Counter32 } atmVclStatTotalCellIns OBJECT-TYPE SYNTAX Counter32 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." ::= { atmVclStatEntry 1 } atmVclStatClp0CellIns OBJECT-TYPE Expires XX [Page 67] draft Supplemental ATM Management Objects December 1996 SYNTAX Counter32 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." ::= { atmVclStatEntry 2 } atmVclStatTotalDiscards OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of valid ATM cells discarded by the traffic policing entity. This includes cells orginally received with CLP=0 and CLP=1." ::= { atmVclStatEntry 3 } atmVclStatClp0Discards OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of valid ATM cells received with CLP=0 an discarded by the traffic policing entity." ::= { atmVclStatEntry 4 } atmVclStatTotalCellOuts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of valid ATM cells transmitted by this VCL. This includes both CLP=0 and CLP=1 cells." ::= { atmVclStatEntry 5 } atmVclStatClp0CellOuts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION Expires XX [Page 68] draft Supplemental ATM Management Objects December 1996 "The total number of valid ATM cells transmitted with CLP=0 by this VCL." ::= { atmVclStatEntry 6 } atmVclStatTaggedOuts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of valid ATM cells tagged by the traffic policing entity from CLP=0 to CLP=1 and transmitted by this VCL." ::= { atmVclStatEntry 7 } -- 12. ATM AAL5 per VCC Statistics Table atmAal5VclStatTable OBJECT-TYPE SYNTAX SEQUENCE OF AtmAal5VclStatEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table provides a collection of objects providing AAL5 configuration and performance statistics of a VCL." ::= { atm2MIBObjects 12 } atmAal5VclStatEntry OBJECT-TYPE SYNTAX AtmAal5VclStatEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry in this table represents a VCL." INDEX { ifIndex, atmVclVpi, atmVclVci } ::= { atmAal5VclStatTable 1 } AtmAal5VclStatEntry ::= SEQUENCE { atmAal5VclTotalErrors Counter32, atmAal5VclInPkts Counter32, atmAal5VclOutPkts Expires XX [Page 69] draft Supplemental ATM Management Objects December 1996 Counter32, atmAal5VclInOctets Counter32, atmAal5VclOutOctets Counter32 } 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 } atmAal5VclInPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of AAL5 CPCS PDUs received on the AAL5 VCC at the interface identified by the ifIndex." ::= { atmAal5VclStatEntry 2 } atmAal5VclOutPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of AAL5 CPCS PDUs transmitted on the AAL5 VCC at the interface identified by the ifIndex." ::= { atmAal5VclStatEntry 3 } atmAal5VclInOctets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets contained in AAL5 CPCS PDUs Expires XX [Page 70] draft Supplemental ATM Management Objects December 1996 received on the AAL5 VCC at the interface identified by the ifIndex." ::= { atmAal5VclStatEntry 4 } atmAal5VclOutOctets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets contained in AAL5 CPCS PDUs transmitted on the AAL5 VCC at the interface identified by the ifIndex." ::= { atmAal5VclStatEntry 5 } -- 13. ATM VC General Information Table atmVclGenTable OBJECT-TYPE SYNTAX SEQUENCE OF AtmVclGenEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "General Information for each VC." ::= { atm2MIBObjects 13 } atmVclGenEntry OBJECT-TYPE SYNTAX AtmVclGenEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry with general information about the ATM VC." AUGMENTS { atmVclEntry } ::= { atmVclGenTable 1 } AtmVclGenEntry ::= SEQUENCE { atmVclGenSigDescrIndex AtmSigDescrParamIndex } Expires XX [Page 71] draft Supplemental ATM Management Objects December 1996 atmVclGenSigDescrIndex OBJECT-TYPE SYNTAX AtmSigDescrParamIndex MAX-ACCESS read-create STATUS current DESCRIPTION "The value of this object identifies the row in the ATM Signalling Descriptor Parameter Table which applies to this VCL." ::= { atmVclGenEntry 1 } -- 13. ATM Interface Configuration Extention table atmInterfaceExtTable OBJECT-TYPE SYNTAX SEQUENCE OF AtmInterfaceExtEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains extra information not defined in the atmInterfaceConfTable per [1]. This table includes the configured and actual minimum VPI/VCI values for all switched VPL/VCLs per ATM interface." ::= { atm2MIBObjects 14 } atmInterfaceExtEntry OBJECT-TYPE SYNTAX AtmInterfaceExtEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry extends the atmInterfaceEntry defined in [1]. Each entry corresponds to an ATM interface." INDEX { ifIndex } ::= { atmInterfaceExtTable 1} AtmInterfaceExtEntry ::= SEQUENCE { atmInterfaceConfigSigType AtmInterfaceType, atmInterfaceActualSigType AtmInterfaceType, atmInterfaceConfigSigSide INTEGER, atmInterfaceActualSigSide INTEGER, atmIntfIlmiAddressRegistration INTEGER, atmIntfIlmiEstablishConnPollInterval Integer32, Expires XX [Page 72] draft Supplemental ATM Management Objects December 1996 atmIntfIlmiCheckConnPollInterval Integer32, atmIntfIlmiConnPollInactivityFactor Integer32, atmIntfIlmiPublicPrivateIndicator INTEGER, atmInterfaceConfMaxSvpcVpi INTEGER, atmInterfaceCurrentMaxSvpcVpi INTEGER, atmInterfaceConfMaxSvccVpi INTEGER, atmInterfaceCurrentMaxSvccVpi INTEGER } atmInterfaceConfigSigType OBJECT-TYPE SYNTAX AtmInterfaceType MAX-ACCESS read-write STATUS current DESCRIPTION "The type of the ATM interface in regards to the signalling that is configured for the interface. Setting this variable to a value of 'other' is not allowed." DEFVAL { autoConfig } ::= { atmInterfaceExtEntry 1 } atmInterfaceActualSigType OBJECT-TYPE SYNTAX AtmInterfaceType MAX-ACCESS read-only STATUS current DESCRIPTION "The type of signalling that is currently being used on the interface. This may reflect a manually configured value for the signalling type, or may be determined by other means such as auto-configuration. A value of `autoConfig' indicates that auto-configuration was requested but has not yet been completed." ::= { atmInterfaceExtEntry 2 } atmInterfaceConfigSigSide OBJECT-TYPE SYNTAX INTEGER { other(1), user(2), network(3) } MAX-ACCESS read-write STATUS current DESCRIPTION "The role of this ATM interface. This value does Expires XX [Page 73] draft Supplemental ATM Management Objects December 1996 not apply and is set to other(1) by agent when the object atmSigConfigSigType is set to `autoConfig', `atmfPnni1Dot0', or `atmfBici2Dot0'." DEFVAL { other } ::= { atmInterfaceExtEntry 3 } atmInterfaceActualSigSide OBJECT-TYPE SYNTAX INTEGER { other(1), user(2), network(3), symmetric(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "The actual role of this signalling entity." ::= { atmInterfaceExtEntry 4 } atmIntfIlmiAddressRegistration OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "Enables/disables ILMI Address Registration on this interface. The configuration takes effect only on the next interface restart." DEFVAL { disabled } ::= { atmInterfaceExtEntry 5 } atmIntfIlmiEstablishConnPollInterval OBJECT-TYPE SYNTAX Integer32 (1..65535) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "The amount of time S between successive transmissions of ILMI messages on this interface for the purpose of detecting establishment of ILMI connectivity." REFERENCE "ATM Forum ILMI 4.0 Section 8.3.1" DEFVAL { 1 } ::= { atmInterfaceExtEntry 6 } atmIntfIlmiCheckConnPollInterval OBJECT-TYPE Expires XX [Page 74] draft Supplemental ATM Management Objects December 1996 SYNTAX Integer32 (0..65535) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "The amount of time T between successive transmissions of ILMI messages on this interface for the purpose of detecting loss of ILMI connectivity. The distinguished value zero disables ILMI connectivity procedures on this interface." REFERENCE "ATM Forum ILMI 4.0 Section 8.3.1" DEFVAL { 5 } ::= { atmInterfaceExtEntry 7 } atmIntfIlmiConnPollInactivityFactor OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-write STATUS current DESCRIPTION "The number K of consecutive polls on this interface for which no ILMI response message is received before ILMI connectivity is declared lost." REFERENCE "ATM Forum ILMI 4.0 Section 8.3.1" DEFVAL { 4 } ::= { atmInterfaceExtEntry 8 } atmIntfIlmiPublicPrivateIndicator OBJECT-TYPE SYNTAX INTEGER { other(1), public(2), private(3) } MAX-ACCESS read-write STATUS current DESCRIPTION "Specifies whether this end of the interface is advertised in ILMI as a device of the `public' or `private' type." DEFVAL { private } ::= { atmInterfaceExtEntry 9 } atmInterfaceConfMaxSvpcVpi OBJECT-TYPE Expires XX [Page 75] draft Supplemental ATM Management Objects December 1996 SYNTAX INTEGER (0..4096) MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum VPI that the signalling stack on the ATM interface is configured to support for allocation to switched virtual path connections." ::= { atmInterfaceExtEntry 10 } atmInterfaceCurrentMaxSvpcVpi OBJECT-TYPE SYNTAX INTEGER (0..4096) MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum VPI that the signalling stack on the ATM interface may currently allocate to switched virtual path connections. This value is the minimum of atmInterfaceConfMaxSvpcVpi, and the atmInterfaceMaxSvpcVpi of the interface's UNI/NNI peer. If the interface does not negotiate with its peer to determine the maximum VPI that can be allocated to SVPCs on the interface, then the value of this object must equal atmInterfaceConfMaxSvpcVpi. " ::= { atmInterfaceExtEntry 11 } atmInterfaceConfMaxSvccVpi OBJECT-TYPE SYNTAX INTEGER (0..4096) MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum VPI that the signalling stack on the ATM interface is configured to support for allocation to switched virtual channel connections." ::= { atmInterfaceExtEntry 12 } atmInterfaceCurrentMaxSvccVpi OBJECT-TYPE SYNTAX INTEGER (0..4096) MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum VPI that the signalling stack on the ATM interface may currently allocate to switched virtual channel connections. This value is the minimum of Expires XX [Page 76] draft Supplemental ATM Management Objects December 1996 atmInterfaceConfMaxSvccVpi, and the atmInterfaceConfMaxSvccVpi of the interface's UNI/NNI peer. If the interface does not negotiate with its peer to determine the maximum VPI that can be allocated to SVCCs on the interface, then the value of this object must equal atmInterfaceConfMaxSvccVpi. " ::= { atmInterfaceExtEntry 13 } -- 15. ILMI Services Registration Table atmIlmiSrvcRegTable OBJECT-TYPE SYNTAX SEQUENCE OF AtmIlmiSrvcRegEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains a list of all the ATM network services known by this device. The characteristics of these services are made available through the ILMI, using the ILMI general- purpose service registry MIB. These services may be made available to all ATM interfaces (atmIlmiSrvcRegIndex = 0) or to some specific ATM interfaces only (atmIlmiSrvcRegIndex = ATM interface index)." ::= { atm2MIBObjects 15 } atmIlmiSrvcRegEntry OBJECT-TYPE SYNTAX AtmIlmiSrvcRegEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a single service provider that is available to the user-side of an adjacent device through the ILMI." INDEX { atmIlmiSrvcRegIndex, atmIlmiSrvcRegServiceID, atmIlmiSrvcRegAddressIndex } ::= { atmIlmiSrvcRegTable 1 } AtmIlmiSrvcRegEntry ::= SEQUENCE { atmIlmiSrvcRegIndex InterfaceIndex, Expires XX [Page 77] draft Supplemental ATM Management Objects December 1996 atmIlmiSrvcRegServiceID OBJECT IDENTIFIER, atmIlmiSrvcRegAddressIndex INTEGER, atmIlmiSrvcRegATMAddress AtmAddr, atmIlmiSrvcRegParm1 OCTET STRING, atmIlmiSrvcRegSource INTEGER, atmIlmiSrvcRegRowStatus RowStatus } atmIlmiSrvcRegIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The ATM interface where the service defined in this entry can be made available to an ATM device attached to this interface. The value of 0 has a special meaning: when an ATM service is defined in an entry whose atmIlmiSrvcRegIndex is zero, the ATM service is available to ATM devices connected to any ATM interface. (default value(s)). When the user-side of an adjacent device queries the content of the ILMI service registry MIB (using the ILMI protocol), the local network-side responds with the ATM services defined in atmIlmiSrvcRegTable entries, provided that these entries are indexed by: - the corresponding interface number (atmIlmiSrvcRegIndex equal to the number of the interface that the adjacent device is connected to) - zero (atmIlmiSrvcRegIndex=0)." ::= { atmIlmiSrvcRegEntry 1 } atmIlmiSrvcRegServiceID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS not-accessible STATUS current Expires XX [Page 78] draft Supplemental ATM Management Objects December 1996 DESCRIPTION "This is the service identifier which uniquely identifies the type of service at the address provided in the table." ::= { atmIlmiSrvcRegEntry 2 } atmIlmiSrvcRegAddressIndex OBJECT-TYPE SYNTAX INTEGER (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An arbitrary integer to differentiate multiple rows containing different ATM addresses for the same service on the same interface. This number needs NOT to be the same as the corresponding ILMI atmfSrvcRegAddressIndex MIB object." ::= { atmIlmiSrvcRegEntry 3 } atmIlmiSrvcRegATMAddress OBJECT-TYPE SYNTAX AtmAddr MAX-ACCESS read-create STATUS current DESCRIPTION "This is the full address of the service. The user-side of the adjacent device may use this address to establish a connection with the service." ::= { atmIlmiSrvcRegEntry 4 } atmIlmiSrvcRegParm1 OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-create STATUS current DESCRIPTION "An octet string used according to the value of atmIlmiSrvcRegServiceID." ::= { atmIlmiSrvcRegEntry 5 } atmIlmiSrvcRegSource OBJECT-TYPE SYNTAX INTEGER { other(1), -- the source of this entry is unknown viaNms(2), -- this entry is created by a Network Manager viaConfig(3) -- this entry is created via other kind of -- configuration mechanism such as the console -- interface Expires XX [Page 79] draft Supplemental ATM Management Objects December 1996 } MAX-ACCESS read-create STATUS current DESCRIPTION "This object is used to describe the source of the entry. The entry can be created by the NMS via SNMP or other configuration mechanism such as the console interface." ::= { atmIlmiSrvcRegEntry 6 } atmIlmiSrvcRegRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object is used to create or destroy an entry from this table." ::= { atmIlmiSrvcRegEntry 7 } -- 16. ILMI Network Prefix Table atmIlmiNetworkPrefixTable OBJECT-TYPE SYNTAX SEQUENCE OF AtmIlmiNetworkPrefixEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table specifying per interface network prefix(es) supplied by the network side of the UNI during ILMI address registration. When no network prefixes are specified for a particular interface, one or more network prefixes based on the switch address(es) may be used for ILMI address registration." ::= { atm2MIBObjects 16 } atmIlmiNetworkPrefixEntry OBJECT-TYPE SYNTAX AtmIlmiNetworkPrefixEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a single network prefix supplied by the network side of the UNI during ILMI address registration. Note that the index variable atmIlmiNetPrefixPrefix is a variable-length string, and as such the rule for variable-length strings in section Expires XX [Page 80] draft Supplemental ATM Management Objects December 1996 7.7 of RFC 1902 applies." INDEX { ifIndex, atmIlmiNetPrefixPrefix } ::= { atmIlmiNetworkPrefixTable 1 } AtmIlmiNetworkPrefixEntry ::= SEQUENCE { atmIlmiNetPrefixPrefix AtmIlmiNetworkPrefix, atmIlmiNetPrefixRowStatus RowStatus } atmIlmiNetPrefixPrefix OBJECT-TYPE SYNTAX AtmIlmiNetworkPrefix MAX-ACCESS not-accessible STATUS current DESCRIPTION "The network prefix specified for use in ILMI address registration." ::= { atmIlmiNetworkPrefixEntry 1 } atmIlmiNetPrefixRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "Used to create, delete, activate and de-activate network prefixes used in ILMI address registration." ::= { atmIlmiNetworkPrefixEntry 2 } -- Trap control objects atmPvplTrapControl OBJECT-TYPE SYNTAX AtmTrapControlType MAX-ACCESS read-write STATUS current DESCRIPTION "This object is used to control the PVP Link traps." DEFVAL { trapAll } ::= { atm2MIBObjects 17 } atmPvclTrapControl OBJECT-TYPE SYNTAX AtmTrapControlType MAX-ACCESS read-write STATUS current Expires XX [Page 81] draft Supplemental ATM Management Objects December 1996 DESCRIPTION "This object is used to control the PVC Link traps." DEFVAL { trapAll } ::= { atm2MIBObjects 18 } atmTrapThreshold OBJECT-TYPE SYNTAX INTEGER (1..2147483647) MAX-ACCESS read-write STATUS current DESCRIPTION "Indicates number of events occurred before generating an ATM trap to the trap receiver. A value of zero indicates no trap is generated." DEFVAL { 1 } ::= { atm2MIBObjects 19 } -- ATM Traps atmPvplChange NOTIFICATION-TYPE OBJECTS { ifIndex, atmVplVpi, atmVplOperStatus } STATUS current DESCRIPTION "This trap signifies that the agent has detected that the atmVplOperStatus object for the permanent VPL has entered or left the up state. This trap shall not be generated if the cause of the VPL status change is a change in status of the underlying interface layer(s)." ::= { atm2MIBTraps 4 } atmPvclChange NOTIFICATION-TYPE OBJECTS { ifIndex, atmVclVpi, atmVclVci, atmVclOperStatus } STATUS current DESCRIPTION "This trap signifies that the agent has detected that the atmVclOperStatus object for the permanent VCL has entered or left the up state. This trap shall not be generated if the cause of the VPL status change is a change in status of the underlying interface layer(s)." ::= { atm2MIBTraps 5 } Expires XX [Page 82] draft Supplemental ATM Management Objects December 1996 -- ************************************************ -- Conformance Information atm2MIBConformance OBJECT IDENTIFIER ::= {atm2MIB 2} atm2MIBGroups OBJECT IDENTIFIER ::= {atm2MIBConformance 1} atm2MIBCompliances OBJECT IDENTIFIER ::= {atm2MIBConformance 2} -- Compliance Statements atm2MIBCompliance 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 { atmSwitchServcHostGroup } -- Objects in the ATM Switch/Service/Host Group OBJECT atmVclStatTotalCellIns DESCRIPTION "This object is mandatory for systems that are supporting per VCC counters." OBJECT atmVclStatClp0CellIns DESCRIPTION "This object is mandatory for systems that are supporting per VCC counters." OBJECT atmVclStatTotalDiscards DESCRIPTION "This object is mandatory for systems that are supporting per VCC counters." Expires XX [Page 83] draft Supplemental ATM Management Objects December 1996 OBJECT atmVclStatClp0Discards DESCRIPTION "This object is mandatory for systems that are supporting per VCC counters." OBJECT atmVclStatTotalCellOuts DESCRIPTION "This object is mandatory for systems that are supporting per VCC counters." OBJECT atmVclStatClp0CellOuts DESCRIPTION "This object is mandatory for systems that are supporting per VCC counters." OBJECT atmVclStatTaggedOuts DESCRIPTION "This object is mandatory for systems that are supporting per VCC counters." OBJECT atmVplStatTotalCellIns DESCRIPTION "This object is mandatory for systems that are supporting per VPC counters." OBJECT atmVplStatClp0CellIns DESCRIPTION "This object is mandatory for systems that are supporting per VPC counters." OBJECT atmVplStatTotalDiscards DESCRIPTION "This object is mandatory for systems that are supporting per VPC counters." OBJECT atmVplStatClp0Discards DESCRIPTION "This object is mandatory for systems that are supporting per VPC counters." OBJECT atmVplStatTotalCellOuts DESCRIPTION "This object is mandatory for systems that are Expires XX [Page 84] draft Supplemental ATM Management Objects December 1996 supporting per VPC counters." OBJECT atmVplStatClp0CellOuts DESCRIPTION "This object is mandatory for systems that are supporting per VPC counters." OBJECT atmVplStatTaggedOuts DESCRIPTION "This object is mandatory for systems that are supporting per VPC counters." OBJECT atmVplLogicalPortDef MIN-ACCESS read-only DESCRIPTION "This object is mandatory for systems support ATM Logical Port interfaces." GROUP atmSwitchServcGroup DESCRIPTION "This group is mandatory for a Switch/Service that implements ATM interfaces." OBJECT atmIfAdminAddrRowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required, and only one of the six enumerated values for the RowStatus textual convention need be supported, specifically: active(1)." OBJECT atmSigSupportClgPtyNumDel MIN-ACCESS read-only DESCRIPTION "Write access is not required. This parameter is required for ATM systems that support only a value of 'disabled(2)' (i.e., the ATM systems does not support the feature associated with the parameter)." OBJECT atmSigSupportClgPtySubAddr MIN-ACCESS read-only DESCRIPTION "Write access is not required. This parameter is required for ATM systems that support only a value of 'disabled(2)' (i.e., the ATM systems does not support Expires XX [Page 85] draft Supplemental ATM Management Objects December 1996 the feature associated with the parameter)." OBJECT atmSigSupportCldPtySubAddr MIN-ACCESS read-only DESCRIPTION "Write access is not required. This parameter is required for ATM systems that support only a value of 'disabled(2)' (i.e., the ATM systems does not support the feature associated with the parameter)." OBJECT atmSigSupportHiLyrInfo MIN-ACCESS read-only DESCRIPTION "Write access is not required. This parameter is required for ATM systems that support only a value of 'disabled(2)' (i.e., the ATM systems does not support the feature associated with the parameter)." OBJECT atmSigSupportLoLyrInfo MIN-ACCESS read-only DESCRIPTION "Write access is not required. This parameter is required for ATM systems that support only a value of 'disabled(2)' (i.e., the ATM systems does not support the feature associated with the parameter)." OBJECT atmSigSupportBlliRepeatInd MIN-ACCESS read-only DESCRIPTION "Write access is not required. This parameter is required for ATM systems that support only a value of 'disabled(2)' (i.e., the ATM systems does not support the feature associated with the parameter)." OBJECT atmSigSupportAALInfo MIN-ACCESS read-only DESCRIPTION "Write access is not required. This parameter is required for ATM systems that support only a value of 'disabled(2)' (i.e., the ATM systems does not support the feature associated with the parameter)." OBJECT atmSigSupportPrefCarrier MIN-ACCESS read-only Expires XX [Page 86] draft Supplemental ATM Management Objects December 1996 DESCRIPTION "Write access is not required." OBJECT atmSvcVpCrossConnectRowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required, and only one of the six enumerated values for the RowStatus textual convention need be supported, specifically: active(1)" OBJECT atmSvcVcCrossConnectRowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required, and only two of the six enumerated values for the RowStatus textual convention need be supported, specifically: active(1)." -- The ATM Host Group GROUP atmHOSTGroup DESCRIPTION "This group is mandatory for a Host that implements ATM interfaces." OBJECT atmVclAddrType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmVclAddrRowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required, and only one of the six enumerated values for the RowStatus textual convention need be supported, specifically: active(1)." OBJECT atmVclGenSigDescrIndex MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmSigDescrParamAalType MIN-ACCESS read-only Expires XX [Page 87] draft Supplemental ATM Management Objects December 1996 DESCRIPTION "Write access is not required." OBJECT atmSigDescrParamAalSscsType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmSigDescrParamBhliType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmSigDescrParamBhliInfo MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmSigDescrParamBbcConnConf MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmSigDescrParamBlliLayer2 MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmSigDescrParamBlliLayer3 MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmSigDescrParamBlliPktSize MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmSigDescrParamBlliSnapId MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmSigDescrParamBlliOuiPid Expires XX [Page 88] draft Supplemental ATM Management Objects December 1996 MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT atmSigDescrParamRowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required, and only one of the six enumerated values for the RowStatus textual convention need be supported, specifically: active(1)." ::= { atm2MIBCompliances 1 } -- ********************************************** -- Units of Conformance -- Mandatory for ATM hosts and switch/service providers atmSwitchServcHostGroup OBJECT-GROUP OBJECTS { atmSigSSCOPConEvents, atmSigSSCOPErrdPdus, atmSigDetectSetupAttempts, atmSigEmitSetupAttempts, atmSigDetectUnavailRoutes, atmSigEmitUnavailRoutes, atmSigDetectUnavailResrcs, atmSigEmitUnavailResrcs, atmSigDetectCldPtyEvents, atmSigEmitCldPtyEvents, atmSigDetectMsgErrors, atmSigEmitMsgErrors, atmSigDetectClgPtyEvents, atmSigEmitClgPtyEvents, atmSigDetectTimerExpireds, atmSigEmitTimerExpireds, atmSigDetectRestarts, atmSigEmitRestarts, atmSigInEstabls, atmSigOutEstabls, atmVclStatTotalCellIns, Expires XX [Page 89] draft Supplemental ATM Management Objects December 1996 atmVclStatClp0CellIns, atmVclStatTotalDiscards, atmVclStatClp0Discards, atmVclStatTotalCellOuts, atmVclStatClp0CellOuts, atmVclStatTaggedOuts, atmVplStatTotalCellIns, atmVplStatClp0CellIns, atmVplStatTotalDiscards, atmVplStatClp0Discards, atmVplStatTotalCellOuts, atmVplStatClp0CellOuts, atmVplStatTaggedOuts, atmVplLogicalPortDef, atmVplLogicalPortIndex, atmInterfaceConfMaxSvpcVpi, atmInterfaceCurrentMaxSvpcVpi, atmInterfaceConfMaxSvccVpi, atmInterfaceCurrentMaxSvccVpi, atmInterfaceConfigSigType, atmInterfaceActualSigType, atmInterfaceConfigSigSide, atmInterfaceActualSigSide, atmIntfIlmiAddressRegistration, atmIntfIlmiEstablishConnPollInterval, atmIntfIlmiCheckConnPollInterval, atmIntfIlmiConnPollInactivityFactor, atmIntfIlmiPublicPrivateIndicator, atmPvplTrapControl, atmPvclTrapControl, atmTrapThreshold } STATUS current DESCRIPTION "A collection of objects providing information for a Switch/Service/Host that implements ATM interfaces." ::= { atm2MIBGroups 1 } atmSwitchServcGroup OBJECT-GROUP OBJECTS { atmIlmiSrvcRegATMAddress, Expires XX [Page 90] draft Supplemental ATM Management Objects December 1996 atmIlmiSrvcRegParm1, atmIlmiSrvcRegSource, atmIlmiSrvcRegRowStatus, atmIlmiNetPrefixRowStatus, atmSigSupportClgPtyNumDel, atmSigSupportClgPtySubAddr, atmSigSupportCldPtySubAddr, atmSigSupportHiLyrInfo, atmSigSupportLoLyrInfo, atmSigSupportBlliRepeatInd, atmSigSupportAALInfo, atmSigSupportPrefCarrier, atmSvcVpCrossConnectCreationTime, atmSvcVpCrossConnectRowStatus, atmSvcVcCrossConnectCreationTime, atmSvcVcCrossConnectRowStatus, atmIfAdminAddrAddressSource, atmIfAdminAddrRowStatus} STATUS current DESCRIPTION "A collection of objects providing information for a Switch/Service that implements ATM interfaces." ::= { atm2MIBGroups 3 } atmHOSTGroup OBJECT-GROUP OBJECTS { atmAal5VclTotalErrors, atmAal5VclInPkts, atmAal5VclOutPkts, atmAal5VclInOctets, atmAal5VclOutOctets, atmVclAddrType, atmVclAddrRowStatus, atmAddrVclAddrType, atmVclGenSigDescrIndex, atmSigDescrParamAalType, atmSigDescrParamAalSscsType, atmSigDescrParamBhliType, atmSigDescrParamBhliInfo, atmSigDescrParamBbcConnConf, atmSigDescrParamBlliLayer2, atmSigDescrParamBlliLayer3, Expires XX [Page 91] draft Supplemental ATM Management Objects December 1996 atmSigDescrParamBlliPktSize, atmSigDescrParamBlliSnapId, atmSigDescrParamBlliOuiPid, atmSigDescrParamRowStatus} STATUS current DESCRIPTION "A collection of objects providing information for a Host that implements ATM interfaces." ::= { atm2MIBGroups 5 } END Expires XX [Page 92] draft Supplemental ATM Management Objects December 1996 11. Acknowledgments This document is a product of the AToMMIB Working Group. Expires XX [Page 93] draft Supplemental ATM Management Objects December 1996 12. References [1] Ahmed, M., Tesink, K., "Definitions of Managed Objects for ATM Management Version June 26, 1996", draft-ietf- atommib-atm1ng-01.txt Bell Communications Research, August 1994. [2] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure of Management Information for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1442, SNMP Research,Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, April 1993. [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] Galvin, J., and K. McCloghrie, "Administrative Model for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1445, Trusted Information Systems, Hughes LAN Systems, April 1993. [5] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol Operations for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1448, SNMP Research,Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, April 1993. [6] McCloghrie, K. and F. Kastenholz, "Evolution of the Interfaces Group of MIB-II", RFC 1573, Hughes LAN Systems, FTP Software, January 1994. [7] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Textual Conventions for SNMPv2", RFC1443, SNMP Research,Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, April 1993. [8] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Conformance Statements for SNMPv2", RFC1444, SNMP Research,Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, April 1993. Expires XX [Page 94] draft Supplemental ATM Management Objects December 1996 [9] ATM Forum, "ATM User-Network Interface, Version 3.0 (UNI 3.0) Specification, Part I", 1994. [10] ATM Forum, "ATM User-Network Interface, Version 3.1 (UNI 3.1) Specification, Part I", November 1994. [11] ITU-T Recommendation Q.2931, "Broadband Integrated Service Digital Network (B-ISDN) Digital Service Signalling System No.2 (DSS2) User-Network Interface (UNI) Layer 3 Specification for Basic Call/Connection Control", September 1994. [12] ATM Forum 94-0471R4, "P-NNI Draft Specification, P-NNI SWG", November 1994. [13] ITU-T Draft Recommendation Q.2110, "Broadband Integrated Service Digital Network (B-ISDN) - ATM Adaptation Layer - Service Specific Connection Oriented Protocol (SSCOP) Specification", 1994. [14] Newton, T., "Baseline Text For LAN Emulation Client Management", ATM Forum Contribution 94-0737R1, Digital Equipment Corporation, January 1995. [15] Brown, T., Tesink, K., "Definitions of Managed Objects for SMDS Interfaces using SMIv2", RFC 1694, Bell Communications Research, August 1994. [16] ITU-T Draft Recommendation Q.2961, "Broadband Integrated Service Digital Network (B-ISDN) Digital Service Signalling System No.2 (DSS2) Support of Additional Traffic Parameters", May 1995. [17] ITU-T Draft Recommendation Q.2971, "Broadband Integrated Service Digital Network (B-ISDN) Digital Service Signalling System No.2 (DSS2) User Network Interface Layer 3 Specification for Point-to-multipoint Call/connection Control", May 1995. [18] ATM Forum, "Interim Inter-switch Signaling Protocol (IISP)Specification, Version 1.0", af-pnni-0026.000, December 1994. Expires XX [Page 95] draft Supplemental ATM Management Objects December 1996 [19] ATM Forum B-ICI Recommendation, - Text to be provided [20] ITU-T Recommendation I.610, "Broadband Integrated Service Digital Network (B-ISDN) Operation and Maintenance Principles and Functions", July 1995. [21] "ATM Forum, af-ilmi-0065.000 "Integrated Local Management Interface (ILMI) Specification Version 4.0" September, 1996. Expires XX [Page 96] draft Supplemental ATM Management Objects December 1996 13. Security Considerations Security issues are not discussed in this memo. 14. Authors' Addresses Faye Ly Bay Networks Communications, Inc. 4401 Great America Pkwy Santa Clara, CA 95052 Phone: (408) 495-1702 EMail: faye@Baynetworks.COM Michael Noto Bell Communications Research Room 1E-348 331 Newman Springs Road P.O. Box 7020 Red Bank, NJ 07701-7020 Phone: (908) 758-5104 EMail: noto@cc.bellcore.com Andrew Smith Extreme Networks 1601 S. De Anza Blvd, #220 Cupertino, CA 95014 Phone: (408) 342 0985 EMail: ansmith@ix.netcom.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 XX [Page 97] draft Supplemental ATM Management Objects December 1996 Table of Contents 1 Status of this Memo ................................... 1 2 Introduction .......................................... 2 3 Change Log ............................................ 2 4 The SNMPv2 Network Management Framework ............... 2 5 Object Definitions .................................... 3 6 Overview .............................................. 3 6.1 Background .......................................... 3 6.2 Important Definitions ............................... 4 6.3 Supported Functions ................................. 6 6.3.1 ATM SVC VC Cross Connect Table .................... 7 6.3.2 ATM SVC VP Cross Connect Table .................... 8 6.3.3 ATM Interface Signalling Statistics Table ......... 9 6.3.3.1 SSCOP Counters .................................. 9 6.3.3.2 Unsupported Service Failures .................... 9 6.3.3.3 ATM Signalling Layer Protocol Errors ............ 10 6.3.3.4 UNI Signalling Sub-layer Statistics ............. 10 6.3.4 ATM Signalling Capability Support ................. 10 6.3.5 Signalling Descriptor Parameter Table ............. 11 6.3.6 ATM Interface Administrative Address Table ........ 12 6.3.7 ATM VPI/VCI to Address Mapping Table .............. 12 6.3.8 ATM Address to VPI/VCI Mapping Table .............. 12 6.3.9 ATM VPL Statistics Table .......................... 12 6.3.10 ATM VPL Logical Port Table ....................... 14 6.3.10.1 ATM Logical Port Interface ..................... 14 6.3.10.2 How to create an ATM logical interface ......... 16 6.3.11 ATM VCL Statistics Table ......................... 17 6.3.12 ATM VC General Information Table ................. 18 6.3.13 ATM Interface Configuration Extention Table ...... 18 6.3.14 ATM Services Registration Table .................. 20 6.3.15 ILMI Network Prefix Table ........................ 21 7 Valid Address Sets / Default Address .................. 22 8 Configuration of VPLs, VCLs, and Cross-Connects ....... 22 9 ATM Related Trap Support .............................. 22 10 Definitions .......................................... 23 11 Acknowledgments ...................................... 93 12 References ........................................... 94 13 Security Considerations .............................. 97 14 Authors' Addresses ................................... 97 Expires XX [Page 98] draft Supplemental ATM Management Objects December 1996 :r svcFeb96 Expires XX [Page 99]   Received: from cnri by ietf.org id aa01165; 14 Feb 97 4:11 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa19638; 14 Feb 97 4:11 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 DAA14771 for ; Fri, 14 Feb 1997 03:49:08 -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 AAA01703 for ; Fri, 14 Feb 1997 00:48:37 -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 AAA26967 for ; Fri, 14 Feb 1997 00:45: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 AAA16720 for ; Fri, 14 Feb 1997 00:48:20 -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 AAA26873 for ; Fri, 14 Feb 1997 00:48:36 -0800 (PST) Received: by sutter.NSD.3Com.COM id AA13474 (5.65c/IDA-1.4.4-910730 for atommib@thumper.bellcore.com); Fri, 14 Feb 1997 00:48:55 -0800 Date: Fri, 14 Feb 1997 00:48:55 -0800 From: Faye Ly Message-Id: <199702140848.AA13474@sutter.NSD.3Com.COM> To: atommib@thumper.bellcore.com Subject: Issues remaining for 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: ISSUE.1296 X-Sun-Content-Lines: 123 Issues remaining for supplemental MIB 09/97 after 09 posting: 1. ATM interface Signalling management This is what we are trying to achieve: 1) be able to turn signalling on/off 2) be able to set/retrieve signalling type, DSS2, UNI3.0, UNI3.1 ... 3) be able to set/retrieve cell format (UNI, NNI and Auto). 4) be able to set/retrieve signalling side (User, Network and symmetric) 5) be able to turn ILMI on/off. 6) be able to set/retrieve interface type (public vs. private). And this is our proposal: . Objects atmSigConfigSide and atmSigActualSide cover the item 1) and 3) listed above. . Objects atmSigConfigType and atmSigActualType cover the item 2). except uniPvcs and nniPvcs. (add two new enums). . Move all these four objects into the atmInterfaceExtTable and rename them to atmInterfaceExtxxxxxxxxx. . Add a new objects atmInterfacefExtIlmiEnabled to the atmInterfaceExtTable to cover the itme 5). . Add a new objects atmInterfaceExtIfType to cover the itme 6). . Rename atmSigTable to atmSigStatsTable since it only contains ATM signalling statistics now. Status: Closed. Mickey's proposal has been included in the 09 draft. 2. atmIfAdminAddrTable clarification This is the intent of the table: 1) this table is meant for the switch/service only. 2) be able to display all ILMI registered ATM addresses. 2) be able to allow configuration of all accessible ATM addresses on this interface for the service provider. This is our proposal: . rename the atmIfAdminAddrTable to atmIfRegisteredAddrTable. . add ilmi(3) enum into the object atmIfRegAddrSource. . clarify the intent of the table in section 6.3.6 ATM Interface Administrative Address Table and the proposed text follows: "6.3.6 ATM Interface Registered Address Table This table contains a list of ATM addresses attatched to the ATM interface. The ATM addresses are either registered via the ILMI or statically configured. The static entries are ATM addresses that can be used for calls to and from a given interface used by the service provider. This table does not provide ATM routing information." Status: Mickey proposed the atmSwitchAddressTable which includes ILMI registered ATM addresses. Pending list consensus that is the better approach. 3. ATM Trap control mechanism: Mickey will provide a new proposal on the mailing list which resemble Soft PVC trap control mechanism. Status: Still under discussion on the mailing list. 4. Party identification: atmVclAddrTable. Does the ATM switch needs to support this table? Some venders think this is a good idea for VC tracing. For the mailing list to discuss. 5. atmSrvcRegTable clarify the usage of viaIlmi. Status: deleted viaIlmi in 09 draft. 6. PVC/PVP up/down counters. Mickey to propose to the mailing list. 7. atmVplStatTable and atmVclStatTable. The description of the counters are not correct. James to provide a picture and a description to clarify on the mailing list. Status: James, please send the picture to the mailing list. 8. ATM prefixes table. Need a table to configure/retrieve ATM prefixes for the ATM switches. Status: Closed. Done in 09 per Mickey's proposal. Not sure whether this table should be provided for a single switch or multiple switches. Up to the mailing list to discuss. Currently it is designed for a single switch. 9. UNI 4.0 support. James(?) to provide a proposal. 10. Section 7. which talks about ATM addresses per interface is not clear and incorrect. We need to move this section in front of the section 6.2 or 6.3 where the atmRegisteredAddrTable is discussed. James or Kaj to provide text for this section. This section should cover: 1) ifPhysAddr 2) ifRecvAddrTable 3) atmRegisteredAddrTable 11. cleanup section 6.3.3.2 Faye to propose a reasonable text to the list. Status: I am not sure I can, any other volunteer? 12. ILMI configured minimum VPI bits and VCI bits. text and MIB need to be corrected. Steve Buchko to provide to the list. Status: Closed. Done in 09 draft per Steve's proposal in the atmInterfaceExtTable.   Received: from cnri by ietf.org id aa05998; 14 Feb 97 8:57 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa07980; 14 Feb 97 8:57 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 IAA18849 for ; Fri, 14 Feb 1997 08:36:32 -0500 (EST) Received: (from smap@localhost) by ns.newbridge.com (8.6.12/8.6.12) id IAA23537 for ; Fri, 14 Feb 1997 08:36:28 -0500 Received: from portero(192.75.23.66) by ns via smap (V1.3) id sma023447; Fri Feb 14 08:36:16 1997 Received: (from smap@localhost) by kanmaster.ca.newbridge.com (8.6.12/8.6.12) id IAA18350; Fri, 14 Feb 1997 08:36:15 -0500 Received: from unknown(138.120.136.153) by kanmaster.ca.newbridge.com via smap (V1.3) id sma018341; Fri Feb 14 08:35:49 1997 Sender: apetti@ca.newbridge.com Message-ID: <33046A33.72EE@newbridge.com> Date: Fri, 14 Feb 1997 08:35:47 -0500 From: Antonio Petti Organization: Newbridge Networks Corporation X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: atommib@thumper.bellcore.com Subject: unsubscribe Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit unsubscribe   Received: from cnri by ietf.org id aa06920; 14 Feb 97 10:12 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa13329; 14 Feb 97 10:12 EST Received: from tsi-telsys.com (tsi-telsys.com [205.230.130.10]) by thumper.bellcore.com (8.8.5/8.8.5) with ESMTP id JAA20601 for ; Fri, 14 Feb 1997 09:50:46 -0500 (EST) Received: from bezerk (205.230.130.124) by tsi-telsys.com with SMTP (Apple Internet Mail Server 1.0); Fri, 14 Feb 1997 09:48:03 -0400 Sender: tmeagher@tsi-telsys.com Message-ID: <33047BAA.71F8@tsi-telsys.com> Date: Fri, 14 Feb 1997 09:50:18 -0500 From: Tim Meagher Organization: TSI TelSys Inc. X-Mailer: Mozilla 3.0 (X11; U; SunOS 5.5.1 sun4m) MIME-Version: 1.0 To: atommib@thumper.bellcore.com Subject: Will someone please tell me how to unsubscribe from this newsgroup? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Thanks -- Tim Meagher TSI Telsys Inc. Senior Software Engineer 7100 Columbia Gateway Dr. tmeagher@tsi-telsys.com Columbia, MD 21046 410-872-3928 (voice) http://www.tsi-telsys.com 410-872-3901 (FAX)   Received: from cnri by ietf.org id aa09522; 14 Feb 97 12:06 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa22192; 14 Feb 97 12:06 EST Received: from tsi-telsys.com (tsi-telsys.com [205.230.130.10]) by thumper.bellcore.com (8.8.5/8.8.5) with ESMTP id LAA24715 for ; Fri, 14 Feb 1997 11:50:09 -0500 (EST) Received: from bezerk (205.230.130.124) by tsi-telsys.com with SMTP (Apple Internet Mail Server 1.0); Fri, 14 Feb 1997 11:47:26 -0400 Sender: tmeagher@tsi-telsys.com Message-ID: <330497A5.6C6D@tsi-telsys.com> Date: Fri, 14 Feb 1997 11:49:41 -0500 From: Tim Meagher Organization: TSI TelSys Inc. X-Mailer: Mozilla 3.0 (X11; U; SunOS 5.5.1 sun4m) MIME-Version: 1.0 To: atommib@thumper.bellcore.com Subject: unsubscribe Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit unsubscribe tmeagher@tsi-telsys.com   Received: from cnri by ietf.org id aa11096; 14 Feb 97 14:04 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa00986; 14 Feb 97 14:04 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 NAA28201 for ; Fri, 14 Feb 1997 13:40:23 -0500 (EST) Received: (from smap@localhost) by ns.newbridge.com (8.6.12/8.6.12) id NAA09207 for ; Fri, 14 Feb 1997 13:40:22 -0500 Received: from portero(192.75.23.66) by ns via smap (V1.3) id sma008999; Fri Feb 14 13:39:51 1997 Received: (from smap@localhost) by kanmaster.ca.newbridge.com (8.6.12/8.6.12) id NAA17931; Fri, 14 Feb 1997 13:39:50 -0500 Received: from unknown(138.120.136.153) by kanmaster.ca.newbridge.com via smap (V1.3) id sma017919; Fri Feb 14 13:39:42 1997 Sender: apetti@ca.newbridge.com Message-ID: <3304B16B.658B@newbridge.com> Date: Fri, 14 Feb 1997 13:39:39 -0500 From: Antonio Petti Organization: Newbridge Networks Corporation X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: atommib@thumper.bellcore.com Subject: unsubscribe Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit unsubscribe apetti@newbridge.com   Received: from cnri by ietf.org id aa13279; 15 Feb 97 16:06 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa03726; 15 Feb 97 16:06 EST Received: from eagle.sntc.com ([204.120.146.2]) by thumper.bellcore.com (8.8.5/8.8.5) with SMTP id PAA22379 for ; Sat, 15 Feb 1997 15:38:28 -0500 (EST) Received: from Microsoft Mail (PU Serial #1487) by eagle.sntc.com (PostalUnion/SMTP(tm) v2.1.8d for Windows NT(tm)) id AA-1997Feb15.144000.1487.36068; Sat, 15 Feb 1997 14:43:02 -0600 From: Steve Senum To: atommib Message-ID: <1997Feb15.144000.1487.36068@eagle.sntc.com> X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Sat, 15 Feb 1997 14:43:02 -0600 Subject: RE: Pos 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}? Steve Senum, sssenum@sntc.com   Received: from cnri by ietf.org id aa06487; 16 Feb 97 8:25 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa05010; 16 Feb 97 8:25 EST Received: from HTSMTP.GIC.GI.COM ([198.102.88.4]) by thumper.bellcore.com (8.8.5/8.8.5) with ESMTP id HAA03555 for ; Sun, 16 Feb 1997 07:58:10 -0500 (EST) Received: from gicpo.gic.gi.com by HTSMTP.GIC.GI.COM (PMDF V5.0-3 #10138) id <01IFH5X835CG002J6D@HTSMTP.GIC.GI.COM> for atommib@thumper.bellcore.com; Sun, 16 Feb 1997 07:59:28 -0400 (EDT) Received: by gicpo.gic.gi.com with Microsoft Mail id <33072F48@gicpo.gic.gi.com>; Sun, 16 Feb 1997 08:01:12 -0800 (PST) Date: Sun, 16 Feb 1997 07:51:00 -0800 (PST) From: "Moore, Rich (HT-MS)" Subject: unsubscribe To: atommib Message-id: <33072F48@gicpo.gic.gi.com> X-Mailer: Microsoft Mail V3.0 Content-transfer-encoding: 7BIT Encoding: 2 TEXT unsubscribe atommib rmoore@gic.gi.com   Received: from cnri by ietf.org id aa04478; 17 Feb 97 3:48 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa17990; 17 Feb 97 3:48 EST Received: from tech.ascom.ch (uranus.be.tech.ascom.ch [139.79.142.16]) by thumper.bellcore.com (8.8.5/8.8.5) with SMTP id DAA17588 for ; Mon, 17 Feb 1997 03:27:41 -0500 (EST) Received: from thun (thun.be.tech.ascom.ch) by tech.ascom.ch (4.1/SMI-4.1/1.1) id AA09681; Mon, 17 Feb 97 09:27:08 +0100 Date: Mon, 17 Feb 97 09:27:08 +0100 From: Peter Rogl Message-Id: <9702170827.AA09681@tech.ascom.ch> To: atommib@thumper.bellcore.com Subject: unsubscribe unsubscribe atommib rogl@tech.ascom.ch   Received: from ietf.org by ietf.org id aa12755; 17 Feb 97 10:06 EST Received: from ietf.ietf.org by ietf.org id aa10379; 17 Feb 97 9:24 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-atm1ng-03.txt Date: Mon, 17 Feb 1997 09:24:10 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9702170924.aa10379@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 Managed Objects for ATM Management Author(s) : K. Tesink Filename : draft-ietf-atommib-atm1ng-03.txt Pages : 100 Date : 02/12/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. 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. 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-atm1ng-03.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-atommib-atm1ng-03.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-atm1ng-03.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: <19970213154658.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-atommib-atm1ng-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-atommib-atm1ng-03.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970213154658.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from cnri by ietf.org id aa14423; 17 Feb 97 10:35 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa14244; 17 Feb 97 10:35 EST Received: from ietf.org (ietf.org [132.151.1.19]) by thumper.bellcore.com (8.8.5/8.8.5) with SMTP id KAA01345 for ; Mon, 17 Feb 1997 10:06:55 -0500 (EST) Received: from ietf.ietf.org by ietf.org id aa12680; 17 Feb 97 10:04 EST To: Faye Ly cc: Cynthia Clark , atommib@thumper.bellcore.com Subject: Re: Posting In-reply-to: Your message of "Fri, 14 Feb 1997 00:32:15 PST." <199702140832.AA13436@sutter.NSD.3Com.COM> Date: Mon, 17 Feb 1997 10:04:04 -0500 From: Cynthia Clark Message-ID: <9702171004.aa12680@ietf.org> Hi Faye, Just for your information, I am currently working on your Internet-Draft . Please note that the most current version is "-08", not "-09". I'll probably send an announcement to the entire IETF regarding your I-D sometime tomorrow or the next day. Kind Regards, Cynthia ------------------------------------------------------ Cynthia Clark, IETF Internet-Drafts Administrator E-mail Address Preference: -------------------------------------------------------   Received: from cnri by ietf.org id aa17353; 17 Feb 97 11:27 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa18231; 17 Feb 97 11:27 EST Received: from bulkrate.cc.bellcore.com (bulkrate.cc.bellcore.com [128.96.96.96]) by thumper.bellcore.com (8.8.5/8.8.5) with SMTP id LAA00515 for ; Mon, 17 Feb 1997 11:01:06 -0500 (EST) From: mgopalakrishna@notes.primeco.com Received: from gatekeeper.primeco.com by bulkrate.cc.bellcore.com with SMTP id AA25571 (5.67b/IDA-1.5 for ); Mon, 17 Feb 1997 11:02:14 -0500 Received: from chqitss06.primeco.com by gatekeeper.primeco.com (SMI-8.6/SMI-SVR4) id JAA28147; Mon, 17 Feb 1997 09:56:15 -0600 Received: by chqitss06.primeco.com(Lotus SMTP MTA Release 1.0.1) id 86256441.0057AC47 ; Mon, 17 Feb 1997 09:57:37 -0500 X-Lotus-Fromdomain: PCS PRIMECO To: atommib@thumper.bellcore.com Message-Id: <86256441:0057584D.00@chqitss06.primeco.com> Date: Mon, 17 Feb 1997 09:55:42 -0500 Subject: unsubscribe Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii unsubscribe atommib mahesh@nit.airtouch.com   Received: from cnri by ietf.org id aa18437; 17 Feb 97 11:53 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa20286; 17 Feb 97 11:53 EST Received: from ornet.ornet.co.il (ornet.co.il [194.90.140.5]) by thumper.bellcore.com (8.8.5/8.8.5) with ESMTP id LAA01216 for ; Mon, 17 Feb 1997 11:31:03 -0500 (EST) Received: from rafiki.ornet.co.il (rafiki.ornet.co.il [194.90.140.17]) by ornet.ornet.co.il (8.7.6/8.7.3) with ESMTP id SAA14164 for ; Mon, 17 Feb 1997 18:30:39 +0200 (IST) From: David Melman Received: (from melman@localhost) by rafiki.ornet.co.il (8.7.6/8.7.3) id SAA22729 for atommib@thumper.bellcore.com; Mon, 17 Feb 1997 18:30:38 +0200 (IST) Message-Id: <199702171630.SAA22729@rafiki.ornet.co.il> Subject: RFC 1595 - SONET MIB - questions To: atommib@thumper.bellcore.com Date: Mon, 17 Feb 1997 18:30:38 +0200 (IST) X-Mailer: ELM [version 2.4ME+ PL21 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hello. It isn't clear to me what the object sonetMediumCircuitIdentifier is suppose to return. What is the "transmission vendor's circuit identifier"? Regarding the object sonetMediumLineType, what is the difference between "short and long range single mode"? Thanks, David _________________________________________________________________________ David Melman ORNET Data Communications Tel: +972-4-9981314 Technologies Ltd. Fax: +972-4-9981315 A SIEMENS company email: melman@ornet.co.il smail: P.O.B 323 Carmiel 21613 Israel   Received: from cnri by ietf.org id aa19168; 17 Feb 97 12:12 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa21751; 17 Feb 97 12:12 EST Received: from ornet.ornet.co.il (ornet.co.il [194.90.140.5]) by thumper.bellcore.com (8.8.5/8.8.5) with ESMTP id LAA01697 for ; Mon, 17 Feb 1997 11:50:17 -0500 (EST) Received: from rafiki.ornet.co.il (rafiki.ornet.co.il [194.90.140.17]) by ornet.ornet.co.il (8.7.6/8.7.3) with ESMTP id SAA14298 for ; Mon, 17 Feb 1997 18:50:12 +0200 (IST) From: David Melman Received: (from melman@localhost) by rafiki.ornet.co.il (8.7.6/8.7.3) id SAA22759 for atommib@thumper.bellcore.com; Mon, 17 Feb 1997 18:50:12 +0200 (IST) Message-Id: <199702171650.SAA22759@rafiki.ornet.co.il> Subject: AToM MIB questions (RFC 1695) To: atommib@thumper.bellcore.com Date: Mon, 17 Feb 1997 18:50:11 +0200 (IST) X-Mailer: ELM [version 2.4ME+ PL21 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hello. Are the objects: atmInterfaceConfVpcs atmInterfaceConfVccs suppose to return dynamic values, that is, do they reflect the number of actually configured VPCs and VCCs, respectively, at that moment in time when the objects are queried? It seems to me that the objects atmInterfaceMaxVpcs atmInterfaceMaxVccs and atmInterfaceMaxActiveVpiBits atmInterfaceMaxActiveVciBits reflect the same values. That is, can't the max VPC be determined by the max active VPI bits? Likewise with max VCC and max VCI bits? I presume not, but I need someone to explain this issue to me... Thanks so much, David _________________________________________________________________________ David Melman ORNET Data Communications Tel: +972-4-9981314 Technologies Ltd. Fax: +972-4-9981315 A SIEMENS company email: melman@ornet.co.il smail: P.O.B 323 Carmiel 21613 Israel   Received: from cnri by ietf.org id aa27964; 17 Feb 97 16:08 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa09316; 17 Feb 97 16:08 EST Received: from HTSMTP.GIC.GI.COM ([198.102.88.4]) by thumper.bellcore.com (8.8.5/8.8.5) with ESMTP id PAA07251 for ; Mon, 17 Feb 1997 15:46:15 -0500 (EST) Received: from gicpo.gic.gi.com by HTSMTP.GIC.GI.COM (PMDF V5.0-3 #10138) id <01IFJ0KLF48G002LIP@HTSMTP.GIC.GI.COM> for atommib@thumper.bellcore.com; Mon, 17 Feb 1997 15:47:19 -0400 (EDT) Received: by gicpo.gic.gi.com with Microsoft Mail id <3308EE5E@gicpo.gic.gi.com>; Mon, 17 Feb 1997 15:48:46 -0800 (PST) Date: Mon, 17 Feb 1997 15:44:00 -0800 (PST) From: "Moore, Rich (HT-MS)" Subject: Help! How do I unsubscribe? To: atommib Message-id: <3308EE5E@gicpo.gic.gi.com> X-Mailer: Microsoft Mail V3.0 Content-transfer-encoding: 7BIT Encoding: 11 TEXT Folks, I unsubscribed from this mailing list weeks ago, But recently I started receiving the posts again. I've deleted the information that told me how to unsubscribe. Can someone email me directly and tell me how to unsubscribe from this group? Thanks, Rich Moore rmoore@gic.gi.com "Jane! Stop this crazy thing!!!"   Received: from cnri by ietf.org id aa29265; 17 Feb 97 16:29 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa10904; 17 Feb 97 16:29 EST Received: from portal.netedge.com (portal.netedge.com [199.170.8.2]) by thumper.bellcore.com (8.8.5/8.8.5) with SMTP id OAA05915 for ; Mon, 17 Feb 1997 14:49:26 -0500 (EST) Received: from NetEdge.COM by portal.netedge.com id AA05742; Mon, 17 Feb 97 14:36:42 EST Received: from raggedmtn.NetEdge.COM by NetEdge.COM id AA07945; Mon, 17 Feb 97 14:51:19 EST Received: by raggedmtn.NetEdge.COM (4.1/NECL-6.15) id AA12747; Mon, 17 Feb 97 14:38:46 EST From: Chris_Martin Message-Id: <9702171938.AA12747@NetEdge.COM> Subject: Re: AToM MIB questions (RFC 1695) To: David Melman Date: Mon, 17 Feb 97 14:38:46 EST Cc: atommib@thumper.bellcore.com In-Reply-To: <199702171650.SAA22759@rafiki.ornet.co.il>; from "David Melman" at Feb 17, 97 6:50 pm X-Mailer: ELM [version 2.3 PL2] > > Hello. > > Are the objects: > > atmInterfaceConfVpcs > atmInterfaceConfVccs > > suppose to return dynamic values, that is, do they reflect the number > of actually configured VPCs and VCCs, respectively, at that moment in > time when the objects are queried? > Yes. > It seems to me that the objects > atmInterfaceMaxVpcs > atmInterfaceMaxVccs > and > atmInterfaceMaxActiveVpiBits > atmInterfaceMaxActiveVciBits > > reflect the same values. That is, can't the max VPC be determined by > the max active VPI bits? Likewise with max VCC and max VCI bits? I > presume not, but I need someone to explain this issue to me... > Not necessarily. For example, suppose atmInterfaceMaxActiveVciBits is 16. The device may only support 1000 VCs. So atmInterfaceMaxVccs would be 1000, not 2^16 -1. In fact, this is a common arrangement with devices that have a hash lookup or use a content addressable memory (CAM) part. They are limited by the depth (size) of the hash but not on addressability. > Thanks so much, > > David > _________________________________________________________________________ > David Melman ORNET Data Communications > Tel: +972-4-9981314 Technologies Ltd. > Fax: +972-4-9981315 A SIEMENS company > email: melman@ornet.co.il > smail: P.O.B 323 Carmiel 21613 Israel > _____________________________________________________________________ _/ _/ _/_/_/_/ _/_/_/_/_/ _/_/_/_/ _/_/_/_/ _/_/_/_/ _/_/_/_/ _/_/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/_/_/ _/ _/_/_/ _/ _/ _/ _/_/ _/_/ _/ _/_/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/_/_/_/ _/ _/_/_/_/ _/_/_/_/ _/_/_/_/ _/_/_/_/ _____________________________________________________________________ Chris Martin INTERNET: martin@NetEdge.com NetEdge Systems PHONE: (919) 991-9253 P.O. Box 14993 FAX: (919) 991-9160 Research Triangle Park, NC 27709-4993   Received: from ietf.org by ietf.org id aa22710; 18 Feb 97 9:55 EST Received: from ietf.ietf.org by ietf.org id aa20624; 18 Feb 97 9:28 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-atm2-08.txt Date: Tue, 18 Feb 1997 09:28:20 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9702180928.aa20624@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 Supplemental Managed Objects for ATM Management Author(s) : F. Ly, M. Noto, A. Smith, K. Tesink Filename : draft-ietf-atommib-atm2-08.txt Pages : 99 Date : 02/17/1997 This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. 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-atm2-08.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-atommib-atm2-08.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-atm2-08.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: <19970217100031.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-atommib-atm2-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-atommib-atm2-08.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970217100031.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from cnri by ietf.org id aa04684; 18 Feb 97 23:41 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa02566; 18 Feb 97 23:41 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 XAA20503 for ; Tue, 18 Feb 1997 23:18:45 -0500 (EST) Received: from jericho.one-o.com (jericho [206.151.128.12]) by one-o.com (SMI-8.6/SMI-SVR4-OOI951120) id UAA29630; Tue, 18 Feb 1997 20:18:43 -0800 Received: (from heard@localhost) by jericho.one-o.com (SMI-8.6/SMI-SVR4) id UAA12736; Tue, 18 Feb 1997 20:18:43 -0800 Date: Tue, 18 Feb 1997 20:18:43 -0800 Message-Id: <199702190418.UAA12736@jericho.one-o.com> To: atommib@thumper.bellcore.com Subject: Re: RFC 1595 - SONET MIB - questions In-Reply-To: <199702171630.SAA22729@rafiki.ornet.co.il> From: "C. M. Heard/VVNET, Inc." Circa 17 Feb 1997 18:30:38 +0200 (IST) David Melman wrote: > > It isn't clear to me what the object sonetMediumCircuitIdentifier is > suppose to return. What is the "transmission vendor's circuit > identifier"? When a Sonet circuit is leased from one of the telephone companies that company will assign a number that identifies the circuit for maintenance (and possibly billing) purposes. This is what is this object (and ifPhysAddress) returns. In my agent the the circuit identifier will be a zero length octet string unless the management station sets a different value. Note that this is possible in the current SONET-MIB draft since the object has a max-access of read-write. That was not true in RFC 1595. > Regarding the object sonetMediumLineType, what is the difference > between "short and long range single mode"? Here's my interpretation: sonetShortSingleMode(2) == GR-253-CORE intermediate reach or G.957 short haul (-8 to -15 dbm power output, 0 to 12 db attenuation, range 0 to 15 km, 1310 or 1550 nm) sonetLongSingleMode(3) == GR-253-CORE long reach or G.957 long haul (+2 to -3 dbm output and 10-24 db attenuation/OC12 or 0 to -5 dbm output and 10-28 db attenuation/OC3, range 0 to 40 km/1310 nm or 0 to 60 km for 1550 nm) I think that these single-mode interface types are the only ones mentioned by the cited standards for OC-3 and OC-12 rates. Thanks for raising the question. > David 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 aa07728; 19 Feb 97 4:12 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa20125; 19 Feb 97 4:12 EST Received: from foxhound.cisco.com (foxhound.cisco.com [171.69.1.171]) by thumper.bellcore.com (8.8.5/8.8.5) with SMTP id DAA24636 for ; Wed, 19 Feb 1997 03:43:59 -0500 (EST) Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by foxhound.cisco.com (8.6.12/8.6.5) with SMTP id AAA24738; Wed, 19 Feb 1997 00:43:28 -0800 From: Mickey Spiegel Message-Id: <199702190843.AAA24738@foxhound.cisco.com> To: atommib@thumper.bellcore.com cc: mspiegel@cisco.com Subject: ATM traffic descriptor types Date: Wed, 19 Feb 97 00:43:28 PST Following is a new proposal for the atmTrafficDescriptorTypes. This is in response to a work item assigned to me at the December meeting. As discussed at the December meeting, the design guidelines that underly this proposal are the following: - For combinations of traffic parameters that are allowed in UNI 3.0 or UNI 3.1, the corresponding object identities remain the same. The definitions have the same meaning regardless of whether RFC1695 or the new atm1ng and atm2TC drafts are used. Defining a new object identity for UBR.1 would not serve any purpose, since it is possible that the old version embodied in RFC1695 is being used, so it would not be possible to distinguish between the old CBR and UBR.1. - The traffic descriptor type does not in and of itself indicate any specific conformance definition. The combination of service category and traffic descriptor type together can indicate a specific conformance definition. This allows for one traffic descriptor type to be applied to more than one conformance definition. However, for each conformance definition, there is only one traffic descriptor type that can be used. For example, in RFC1695 the atmNoClpNoScr type applies for both CBR connections using the UNI 3.0/3.1 conformance definition for PCR, and the UBR.1 conformance definition. - For combinations of traffic parameters corresponding to new services (CBR.1, VBR.1, and UBR.2), new object identities are proposed. Note that UNI Signalling 4.0 has taken a similar approach. To indicate the CBR.1 and VBR.1 conformance definitions, new ATM Transfer Capability codepoints must be used. If these codepoints are used and the path crosses a UNI 3.0 or UNI 3.1 interface, the call will be rejected. The terminology used for the new CBR.1 and VBR.1 codepoints follows that of the TM 4.0 specification, which calls these conformance definitions "CLP-transparent". Mickey Spiegel Cisco Systems ------------------------------------------------------------------------ -- 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 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} 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 "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 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: 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} ------------------------------------------------------------------------   Received: from cnri by ietf.org id aa21588; 19 Feb 97 12:27 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa21288; 19 Feb 97 12:27 EST Received: from ornet.ornet.co.il (ornet.co.il [194.90.140.5]) by thumper.bellcore.com (8.8.5/8.8.5) with ESMTP id MAA05594 for ; Wed, 19 Feb 1997 12:00:12 -0500 (EST) Received: (from melman@localhost) by ornet.ornet.co.il (8.7.6/8.7.3) id SAA00658 for atommib@thumper.bellcore.com; Wed, 19 Feb 1997 18:59:08 +0200 (IST) From: David Melman Message-Id: <199702191659.SAA00658@ornet.ornet.co.il> Subject: RFC 1695 question To: atommib@thumper.bellcore.com Date: Wed, 19 Feb 1997 18:59:08 +0200 (IST) X-Mailer: ELM [version 2.4ME+ PL21 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi. I'm still struggling with the following objects: atmInterfaceMaxVpcs atmInterfaceMaxVccs atmInterfaceMaxActiveVpiBits atmInterfaceMaxActiveVciBits (Thanks to Chris Martin and David Horton for your inputs earlier.) In our ATM chipset, we have 10 bits to play with such that VCI active bits + VPI active bits = 10 and 0 >= VPI active bits <= 5 So, it seems to me that the max num VPCs and VCCs are a direct function of the number of active bits defined for each, i.e. 2^num-active-bits. Thus I want to make atmInterfaceMaxVpcs and atmInterfaceMaxVccs read-only and simply reflect the corresponding active bit values. Is that reasonable? Now, how to deal with the active bit objects... Together, the two objects (atmInterfaceMaxActiveVpiBits and atmInterfaceMaxActiveVciBits) must have a sum of exactly 10. One option could be to make just one of the objects read-write, and the other read-only. Thus when performing a SET of the read-write object, the other one will always be updated to be 10 minus the new value (a side-effect). Or, we can make both read-write, in which case there are several possible scenarios of SET PDUs: 1) SET PDU which contains just one of the two objects. Should the agent reject it if the sum of the new value together with the existing value != 10? Or should the SET be accepted and have a side-affect of setting the other object to 10 minus the new_value? Or perhaps we should not accept a SET with just one of these objects in the PDU, but require both to be set together (scenario 2). 2) SET PDU which contains both objects Should the agent require the sum to be equal to 10, and otherwise reject the SET PDU? Thanks David _________________________________________________________________________ David Melman ORNET Data Communications Tel: +972-4-9981314 Technologies Ltd. Fax: +972-4-9981315 A SIEMENS company email: melman@ornet.co.il smail: P.O.B 323 Carmiel 21613 Israel   Received: from cnri by ietf.org id aa24187; 19 Feb 97 13:01 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa22453; 19 Feb 97 13:01 EST Received: from mail.madge.com (mail.madge.com [205.184.45.3]) by thumper.bellcore.com (8.8.5/8.8.5) with SMTP id MAA06812 for ; Wed, 19 Feb 1997 12:38:03 -0500 (EST) Received: from Connect2 Message Router by mail.madge.com via Connect2-SMTP 4.00; Wed, 19 Feb 97 06:38:53 -0800 Message-ID: Date: Wed, 19 Feb 97 11:15:52 -0000 From: Andrew Juniper LAN-SP Sender: Andrew Juniper LAN-SP Organization: Madge Networks To: atommib@thumper.bellcore.com Cc: Kaizhen Du INF-SP , "Howard Urmenyi P&T:WL" , Austin Williams P&T-SP Subject: atmInterface[Conf|Current]MinSvccVci X-mailer: Connect2-SMTP 4.00 MHS to SMTP Gateway All, 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? 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). thanks, Andy ---------------------------------- Andy Juniper ajuniper@madge.com +44 (1753) 661485 ---------------------------------- Drive defensively. And remember that the best form of defence is a good offence.   Received: from cnri by ietf.org id aa12262; 19 Feb 97 19:25 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa03327; 19 Feb 97 19:25 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 SAA19248 for ; Wed, 19 Feb 1997 18:48:34 -0500 (EST) Received: (from smap@localhost) by ns.newbridge.com (8.6.12/8.6.12) id SAA01037; Wed, 19 Feb 1997 18:48:32 -0500 Received: from portero(192.75.23.66) by ns via smap (V1.3) id sma001001; Wed Feb 19 18:48:13 1997 Received: (from smap@localhost) by kanmaster.ca.newbridge.com (8.6.12/8.6.12) id SAA12877; Wed, 19 Feb 1997 18:48:08 -0500 Received: from thor121.ca.newbridge.com(138.120.121.43) by kanmaster.ca.newbridge.com via smap (V1.3) id sma012825; Wed Feb 19 18:45:42 1997 Received: from candy.newbridge (candy [138.120.146.136]) by thor.ca.newbridge.com (8.6.12/8.6.12) with SMTP id SAA00795; Wed, 19 Feb 1997 18:45:41 -0500 From: Steve Buchko Message-Id: <199702192345.SAA00795@thor.ca.newbridge.com> Subject: Re: (Fwd) atmInterface[Conf|Current]MinSvccVci To: atommib@thumper.bellcore.com Date: Wed, 19 Feb 1997 18:45:32 -0500 (EST) Cc: fayely@3com.com X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Andrew Juniper wrote: > All, > > 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? I don't believe so, I think those objects were inadvertently removed from the mib when the Vpi objects were changed. We still need atmInterfaceConfMinSvccVci and atmInterfaceCurrentMinSvccVci. 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 aa28319; 20 Feb 97 5:56 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa06917; 20 Feb 97 5:56 EST Received: from mail.madge.com (mail.madge.com [205.184.45.3]) by thumper.bellcore.com (8.8.5/8.8.5) with SMTP id FAA29836 for ; Thu, 20 Feb 1997 05:21:44 -0500 (EST) Received: from Connect2 Message Router by mail.madge.com via Connect2-SMTP 4.00; Thu, 20 Feb 97 01:52:27 -0800 Message-ID: <1913E17301560C00@mail.madge.com> In-Reply-To: <1413E17301560C00> Date: Thu, 20 Feb 97 9:42:12 -0000 From: Andrew Juniper LAN-SP Sender: Andrew Juniper LAN-SP Organization: Madge Networks To: atommib@thumper.bellcore.com Cc: Kaizhen Du INF-SP , "Howard Urmenyi P&T:WL" , fayely@3com.com, Austin Williams P&T-SP Subject: Re: (Fwd) atmInterface[Conf|Current]MinSvccVci X-mailer: Connect2-SMTP 4.00 MHS to SMTP Gateway Steve Buchko wrote: >> 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? > > I don't believe so, I think those objects were inadvertently removed from > the mib when the Vpi objects were changed. We still need > atmInterfaceConfMinSvccVci and > atmInterfaceCurrentMinSvccVci. Given that the vpi values are now configured as maximum values rather than minimum values, how possible would it be to have maximum vci values? I realise that the minimum vci values are required to reserve space for ILMI and Signalling etc, but would it not be useful to be able to configure the vci ranges such that the space reserved (presumably) for PVCs is at the high end of the range rather than the low end? Thanks, Andy ---------------------------------- Andy Juniper ajuniper@madge.com +44 (1753) 661485 ---------------------------------- Drive defensively. And remember that the best form of defence is a good offence.   Received: from cnri by ietf.org id aa07218; 20 Feb 97 10:44 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa13256; 20 Feb 97 10:45 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 KAA05996 for ; Thu, 20 Feb 1997 10:20:27 -0500 (EST) Received: (from smap@localhost) by ns.newbridge.com (8.6.12/8.6.12) id KAA09534; Thu, 20 Feb 1997 10:19:05 -0500 Received: from portero(192.75.23.66) by ns via smap (V1.3) id sma009418; Thu Feb 20 10:18:52 1997 Received: (from smap@localhost) by kanmaster.ca.newbridge.com (8.6.12/8.6.12) id KAA27188; Thu, 20 Feb 1997 10:18:50 -0500 Received: from thor121.ca.newbridge.com(138.120.121.43) by kanmaster.ca.newbridge.com via smap (V1.3) id smaa26943; Thu Feb 20 10:16:17 1997 Received: from candy.newbridge (candy [138.120.146.136]) by thor.ca.newbridge.com (8.6.12/8.6.12) with SMTP id KAA04241; Thu, 20 Feb 1997 10:00:56 -0500 From: Steve Buchko Message-Id: <199702201500.KAA04241@thor.ca.newbridge.com> Subject: Re: (Fwd) atmInterface[Conf|Current]MinSvccVci To: Andrew Juniper LAN-SP Date: Thu, 20 Feb 1997 10:00:19 -0500 (EST) Cc: atommib@thumper.bellcore.com, kdu@madge.com, hurmenyi@madge.com, fayely@3com.com, awilliam@madge.com In-Reply-To: <1913E17301560C00@mail.madge.com> from "Andrew Juniper LAN-SP" at Feb 20, 97 09:42:12 am X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Andrew Juniper LAN-SP wrote: > > Steve Buchko wrote: > >> 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? > > > > I don't believe so, I think those objects were inadvertently removed from > > the mib when the Vpi objects were changed. We still need > > atmInterfaceConfMinSvccVci and > > atmInterfaceCurrentMinSvccVci. > > Given that the vpi values are now configured as maximum values rather than > minimum values, how possible would it be to have maximum vci values? I > realise that the minimum vci values are required to reserve space for ILMI > and Signalling etc, but would it not be useful to be able to configure the > vci ranges such that the space reserved (presumably) for PVCs is at the high > end of the range rather than the low end? This was discussed at great length in the ATM Forum, when the ILMI 4.0 specification was being developed. The decision was to stay with MinSvccVci, so that PVCs would be at the low end of the range. Unfortunately, that was almost a year ago, and I can't remember the technical reasons why some vendors preferred to keep PVCs at the low end of the vci range (I was relatively indifferent as to high end vs. low end for PVCs). In any case, the atommib must align with the ILMI MIB for these parameters, and the ILMI mib uses MinSvccVci. 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 aa02663; 20 Feb 97 19:50 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa27310; 20 Feb 97 19:50 EST Received: from ns.hp.com (daemon@ns.hp.com [15.255.152.6]) by thumper.bellcore.com (8.8.5/8.8.5) with ESMTP id TAA23958 for ; Thu, 20 Feb 1997 19:18:21 -0500 (EST) Received: from palrel3.hp.com ([15.81.184.10]) by ns.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA096825743; Thu, 20 Feb 1997 13:55:49 -0800 Received: from salsa.ptp.hp.com (lrios@salsa.ptp.hp.com [15.8.13.136]) by palrel3.hp.com with SMTP (8.7.5/8.7.3) id NAA21123 for ; Thu, 20 Feb 1997 13:55:28 -0800 (PST) Message-Id: <199702202155.NAA21123@palrel3.hp.com> Received: by salsa.ptp.hp.com (1.38.193.4/16.2) id AA02685; Thu, 20 Feb 1997 15:49:57 -0600 From: Lara Rios Subject: latest ATM mibs To: atommib@thumper.bellcore.com Date: Thu, 20 Feb 97 15:49:57 CST Mailer: Elm [revision: 70.85] Hi whoever this email goes to, I am interested in getting the latest mib file for ATM. I run the backbone monitoring process for HP's wide area network, we are soon deploying ATM so I need to see what mibs are available, and since I am sord of new at this, don't really know where to look (on the web). thanks Lara -- --------------------------------------------------- Lara Rios Hewlett-Packard Technology Infrastructure Services Sunnyvale Blg.101 Telnet: 1-773-6741 phone: (408) 773-6741 email: lrios@salsa.ptp.hp.com ----------------------------------------------------   Received: from cnri by ietf.org id aa22301; 21 Feb 97 17:45 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa25837; 21 Feb 97 17:45 EST Received: from webserver.casc.com (webserver.casc.com [152.148.41.200]) by thumper.bellcore.com (8.8.5/8.8.5) with SMTP id RAA23025 for ; Fri, 21 Feb 1997 17:18:35 -0500 (EST) Received: from casc.com (alpo.casc.com [152.148.10.6]) by webserver.casc.com (8.6.12/8.6.12) with ESMTP id RAA28199 for ; Fri, 21 Feb 1997 17:14:01 -0500 Received: from stock.cascade by casc.com (SMI-8.6/SMI-SVR4-bob.2) id RAA02428; Fri, 21 Feb 1997 17:16:57 -0500 Received: by stock.cascade (5.x/SMI-SVR4) id AA10235; Fri, 21 Feb 1997 17:16:55 -0500 Date: Fri, 21 Feb 1997 17:16:55 -0500 From: Mark Libby Message-Id: <9702212216.AA10235@stock.cascade> To: atommib@thumper.bellcore.com Subject: TM 4.0 support in AToM MIB X-Sun-Charset: US-ASCII I have been looking at the definitions of the traffic descriptor types in the draft-ietf-atommib-atm2TC-05. In looking at the new definitions as compared to the definitions in rfc1695, the only major difference is the addition of the CDVT parameter to some of the traffic descriptor types. TM 4.0 specifies and UNI 4.0 supports for SVCs end-to-end cell delay variation, cell loss ratio and cell transit delay. Is there a way to specify via the AToM MIB these new parameters for PVCs and SPVCs? I have looked through the latest drafts and cannot find a method for specifying these parameters. Mark Libby ---------------------------------------------------------------------- Mark Libby e-mail: libby@casc.com Senior Software Engineer mlibby@pcmail.casc.com Cascade Communications Corporation tel: (508) 952-1480 5 Carlisle Road fax: (508) 392-9250 Westford, MA 01886   Received: from cnri by ietf.org id aa23006; 21 Feb 97 18:08 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa26318; 21 Feb 97 18:08 EST Received: from stilton.cisco.com (stilton.cisco.com [171.69.1.161]) by thumper.bellcore.com (8.8.5/8.8.5) with SMTP id RAA24162 for ; Fri, 21 Feb 1997 17:49:15 -0500 (EST) Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by stilton.cisco.com (8.6.12/8.6.5) with SMTP id OAA01488; Fri, 21 Feb 1997 14:48:37 -0800 From: "Michael H. Grobelch" Message-Id: <199702212248.OAA01488@stilton.cisco.com> To: Mark Libby cc: atommib@thumper.bellcore.com Subject: Re: TM 4.0 support in AToM MIB In-reply-to: Your message of "Fri, 21 Feb 97 17:16:55 EST." <9702212216.AA10235@stock.cascade> Date: Fri, 21 Feb 97 14:48:37 PST >Date: Fri, 21 Feb 1997 17:16:55 -0500 >From: libby@stock.casc.com (Mark Libby) >Message-Id: <9702212216.AA10235@stock.cascade> >To: atommib@thumper.bellcore.com >Subject: TM 4.0 support in AToM MIB > >I have been looking at the definitions of the traffic descriptor types in >the draft-ietf-atommib-atm2TC-05. In looking at the new definitions as >compared to the definitions in rfc1695, the only major difference is the >addition of the CDVT parameter to some of the traffic descriptor types. > >TM 4.0 specifies and UNI 4.0 supports for SVCs end-to-end cell delay variation, >cell loss ratio and cell transit delay. Is there a way to specify via the >AToM MIB these new parameters for PVCs and SPVCs? I have looked through the >latest drafts and cannot find a method for specifying these parameters. > >Mark Libby > >---------------------------------------------------------------------- >Mark Libby e-mail: libby@casc.com >Senior Software Engineer mlibby@pcmail.casc.com >Cascade Communications Corporation tel: (508) 952-1480 >5 Carlisle Road fax: (508) 392-9250 >Westford, MA 01886 > Mark, you might want to look at draft-ietf-atommib-atm1ng-03.txt, as we've introduced Service Category there (atmServiceCategory). I don't think the group has undertaken to "do" TM 4.0 in the current iteration of MIBs. But for the future: I wouldn't neccesarily see the parameters you mention as appropriate for PVCs anyway. Perhaps: - specify what a switch offers per interface in terms of adding-on to CTD and PPCDV, and it's minimum CLR. This would allow a management station to determine whether to route a PVC through the interface. - for SVCs, allow specification of maximum CTD, max PPCDV, and minimum CLR to be signalled. This would apply to the whole VCC, not individual VCL's. Given the above, I don't know if we should bundle the QOS parameters into the Traffic Table. Perhaps have a QOS table? My $.02, Mike ---------------------------------------------------------- Michael Grobelch (grobelch@cisco.com) (408)-526-7348 SJ-G   Received: from cnri by ietf.org id aa21002; 23 Feb 97 22:23 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa20203; 23 Feb 97 22:23 EST Received: from info.curtin.edu.au (root@info.curtin.edu.au [134.7.70.222]) by thumper.bellcore.com (8.8.5/8.8.5) with ESMTP id VAA02331 for ; Sun, 23 Feb 1997 21:58:22 -0500 (EST) Received: from atri.curtin.edu.au ([134.7.130.21]) by info.curtin.edu.au (8.8.5/8.8.5) with SMTP id KAA28028; Mon, 24 Feb 1997 10:58:11 +0800 (WST) Received: from Josef.atri by atri.curtin.edu.au (4.1/ATRI-1.1) id AA27653; Mon, 24 Feb 97 10:57:22 WST Date: Mon, 24 Feb 97 10:57:22 WST From: Peter Jones Message-Id: <9702240257.AA27653@atri.curtin.edu.au> To: atommib@thumper.bellcore.com Subject: correlation to ILMI Cc: kaj@cc.bellcore.com, jn@info.curtin.edu.au Hi There, I have a question for the list about the recent atm1ng draft and it's harmonisation with ILMI. Should add atmInterfaceCurrentMaxVpcs and atmInterfaceCurrentMaxVccs attributes be added? According to ILMI V4.0 - Sections 8.2.3.5 Maximum Number of VCCs and 8.2.3.6 Maximum Number of VPCs, the IME is supposed to negotiate about the maximum numbers of VPCs and VCCs allowed across the link in the same way the the number of active bits is negotiated. Since atm1ng-03 includes atmInterfaceMaxActiveVpiBits and atmInterfaceCurrentMaxVpiBits atmInterfaceMaxActiveVciBits and atmInterfaceCurrentMaxVciBit I think the maximum numbers of VPCs and VCCs have the same type of structure, i.e. atmInterfaceMaxVpcs and atmInterfaceCurrentMaxVpcs atmInterfaceMaxVccs and atmInterfaceCurrentMaxVccs I have already run this past Kaj. His reply was: > did you look at the revised supplemental mib that faye posted? > that should have the stuff you're asking for. if not can you > send something to the list? i want to make sure that we get > it right before we wrap up. > > kaj I have had a quick look at as posted recently and it does not seem to cover this. regards Peter Jones _______________________________________________________________________ Peter Jones. Australian Telecommunication Project Manager Research Institute (ATRI) .-_|\ Network Management Curtin Uni of Technology / \ Phone: +61 9 351 3581 Bentley WA, 6102. P_.-._/ Fax: +61 9 351 3244 Australia. o e-mail: peter@atri.curtin.edu.au _______________________________________________________________________   Received: from cnri by ietf.org id aa05785; 24 Feb 97 15:24 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa20614; 24 Feb 97 15:24 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 OAA19103 for ; Mon, 24 Feb 1997 14:45:50 -0500 (EST) Received: from joker (joker.bellcore.com) by tbird.cc.bellcore.com with SMTP id AA17586 (5.67b/IDA-1.5 for ); Mon, 24 Feb 1997 14:45:45 -0500 Received: from nv-ktesink.cc.bellcore.com by joker (4.1/4.7) id AA28074; Mon, 24 Feb 97 14:47:33 EST Date: Mon, 24 Feb 97 14:47:33 EST X-Station-Sent-From: joker.bellcore.com Message-Id: <3.0.16.19970224144601.19af342c@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: atm tests Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" hi, thanks to Dawn we found an apparent redundancy in the atm test mib; the atmLoopbackLocID and atmLoopbackSrcID seem to be redundant with the d in atmLoopbackVcSegment.d so we can do: - remove d and atmLoopbackSrcID, or - remove atmLoopbackLocID and atmLoopbackSrcID opinions? 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 aa10226; 25 Feb 97 1:41 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa02999; 25 Feb 97 1:41 EST Received: from zeitnet.com (rome.zeitnet.com [204.95.77.95]) by thumper.bellcore.com (8.8.5/8.8.5) with SMTP id WAA25250 for ; Mon, 24 Feb 1997 22:38:06 -0500 (EST) Received: from smtpgw.zeitnet.com by zeitnet.com (8.6.12/SMI-4.1) id TAA24382; Mon, 24 Feb 1997 19:36:51 -0800 Received: by smtpgw.zeitnet.com with Microsoft Mail id <33125E3C@smtpgw.zeitnet.com>; Mon, 24 Feb 97 19:36:28 PST From: Joseph Raja To: Steve Buchko Cc: Joseph Raja , atommib Subject: Re: (Fwd) atmInterface[Conf|Current]MinSvccVci Date: Mon, 24 Feb 97 19:35:00 PST Message-ID: <33125E3C@smtpgw.zeitnet.com> Encoding: 70 TEXT X-Mailer: Microsoft Mail V3.0 If atmInterface[Conf|Current]MinSvccVpi and atmInterface[Conf|Current]MinSvccVci specify the minimum values that a signalling stack can assign does it preclude PVC's being created in that range ? atm2-08.txt has no clarification in this regard. thanks jlr ---------- From: Steve Buchko To: ajuniper Cc: atommib; kdu; hurmenyi; fayely; awilliam Subject: Re: (Fwd) atmInterface[Conf|Current]MinSvccVci Date: Thursday, February 20, 1997 10:00AM Andrew Juniper LAN-SP wrote: > > Steve Buchko wrote: > >> 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? > > > > I don't believe so, I think those objects were inadvertently removed from > > the mib when the Vpi objects were changed. We still need > > atmInterfaceConfMinSvccVci and > > atmInterfaceCurrentMinSvccVci. > > Given that the vpi values are now configured as maximum values rather than > minimum values, how possible would it be to have maximum vci values? I > realise that the minimum vci values are required to reserve space for ILMI > and Signalling etc, but would it not be useful to be able to configure the > vci ranges such that the space reserved (presumably) for PVCs is at the high > end of the range rather than the low end? This was discussed at great length in the ATM Forum, when the ILMI 4.0 specification was being developed. The decision was to stay with MinSvccVci, so that PVCs would be at the low end of the range. Unfortunately, that was almost a year ago, and I can't remember the technical reasons why some vendors preferred to keep PVCs at the low end of the vci range (I was relatively indifferent as to high end vs. low end for PVCs). In any case, the atommib must align with the ILMI MIB for these parameters, and the ILMI mib uses MinSvccVci. 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 aa14479; 25 Feb 97 3:09 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa04383; 25 Feb 97 3:09 EST Received: from foxhound.cisco.com (foxhound.cisco.com [171.69.1.171]) by thumper.bellcore.com (8.8.5/8.8.5) with SMTP id CAA28978 for ; Tue, 25 Feb 1997 02:48:04 -0500 (EST) Received: (kzm@localhost) by foxhound.cisco.com (8.6.12/8.6.5) id XAA22084; Mon, 24 Feb 1997 23:46:58 -0800 From: Keith McCloghrie Message-Id: <199702250746.XAA22084@foxhound.cisco.com> Subject: Re: (Fwd) atmInterface[Conf|Current]MinSvccVci To: Joseph Raja Date: Mon, 24 Feb 1997 23:46:57 -0800 (PST) Cc: stevebu@ca.newbridge.com, Joseph@smtpgw.zeitnet.com, atommib@thumper.bellcore.com In-Reply-To: <33125E3C@smtpgw.zeitnet.com> from "Joseph Raja" at Feb 24, 97 07:35:00 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > If atmInterface[Conf|Current]MinSvccVpi and > atmInterface[Conf|Current]MinSvccVci specify the minimum values that a > signalling stack can assign does it preclude PVC's being created in that > range ? atm2-08.txt has no clarification in this regard. No. However, while PVCs can be setup anywhere, the purpose of restricting the values which SVCs can use, is to reserve the other values for PVCs. Keith.   Received: from cnri by ietf.org id aa10872; 25 Feb 97 9:54 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa11777; 25 Feb 97 9:54 EST Received: from ihgw1.lucent.com (ihgw1.lucent.com [207.19.48.1]) by thumper.bellcore.com (8.8.5/8.8.5) with SMTP id JAA06462 for ; Tue, 25 Feb 1997 09:20:58 -0500 (EST) From: dxie@mtgbcs.mt.lucent.com Received: from mtgbcs.mt.lucent.com by ihig1.firewall.lucent.com (SMI-8.6/EMS-L sol2) id IAA13264; Tue, 25 Feb 1997 08:30:37 -0600 Received: from mtpcs52-102 by mtgbcs.mt.lucent.com (5.0/EMS-L sol2) id AA21080; Tue, 25 Feb 1997 09:18:27 -0500 Message-Id: <970225092520.ZM2887@mtpcs52-102> Date: Tue, 25 Feb 1997 09:25:17 -0400 In-Reply-To: Kaj Tesink "atm tests" (Feb 24, 2:47pm) References: <3.0.16.19970224144601.19af342c@joker.bellcore.com> X-Mailer: Z-Mail 4.0 (4.0.0 Aug 21 1995) To: Kaj Tesink , atommib@thumper.bellcore.com Subject: Re: atm tests Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Feb 24, 2:47pm, Kaj Tesink wrote: > Subject: atm tests > hi, > > thanks to Dawn we found an apparent redundancy in > the atm test mib; the atmLoopbackLocID and atmLoopbackSrcID > seem to be redundant with the d in atmLoopbackVcSegment.d > so we can do: > - remove d and atmLoopbackSrcID, or > - remove atmLoopbackLocID and atmLoopbackSrcID Kaj: I think we shall remove atmLoopbackLocID and atmLoopbackSrcID and make atmLoopbackID to have read-write permission. -- Dawn Xie dawnxie@lucent.com (908) 957-2066 > > opinions? > > 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 _/ > _/ _/ > _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ _/ > > >-- End of excerpt from Kaj Tesink   Received: from cnri by ietf.org id aa26297; 25 Feb 97 15:14 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa20019; 25 Feb 97 15:14 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 OAA18413 for ; Tue, 25 Feb 1997 14:49:15 -0500 (EST) Received: (from smap@localhost) by ns.newbridge.com (8.6.12/8.6.12) id OAA28175; Tue, 25 Feb 1997 14:48:36 -0500 Received: from portero(192.75.23.66) by ns via smap (V1.3) id sma028054; Tue Feb 25 14:48:11 1997 Received: (from smap@localhost) by kanmaster.ca.newbridge.com (8.6.12/8.6.12) id OAA00657; Tue, 25 Feb 1997 14:48:07 -0500 Received: from thor121.ca.newbridge.com(138.120.121.43) by kanmaster.ca.newbridge.com via smap (V1.3) id sma028913; Tue Feb 25 14:29:12 1997 Received: from candy.newbridge (candy [138.120.146.136]) by thor.ca.newbridge.com (8.6.12/8.6.12) with SMTP id OAA22376; Tue, 25 Feb 1997 14:29:10 -0500 From: Steve Buchko Message-Id: <199702251929.OAA22376@thor.ca.newbridge.com> Subject: Re: (Fwd) atmInterface[Conf|Current]MinSvccVci To: Keith McCloghrie Date: Tue, 25 Feb 1997 14:29:08 -0500 (EST) Cc: joseph.raja@zeitnet.com, stevebu@ca.newbridge.com, Joseph@smtpgw.zeitnet.com, atommib@thumper.bellcore.com In-Reply-To: <199702250746.XAA22084@foxhound.cisco.com> from "Keith McCloghrie" at Feb 24, 97 11:46:57 pm X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Keith McCloghrie wrote: > > > If atmInterface[Conf|Current]MinSvccVpi and > > atmInterface[Conf|Current]MinSvccVci specify the minimum values that a > > signalling stack can assign does it preclude PVC's being created in that > > range ? atm2-08.txt has no clarification in this regard. > > No. However, while PVCs can be setup anywhere, the purpose of > restricting the values which SVCs can use, is to reserve the other > values for PVCs. > > Keith. > Also note that it is atmInterface[Conf|Current]MaxSvccVpi, and ^^^ atmInterface[Conf|Current]MinSvccVci. ^^^ The reason for this (besides consistency with the ILMI MIB :-) ), was that VPI 0 is almost always used for SVCs. Therefore, in order to allow a contiguous range of VPIs to be reserved for SVCs, the range starts at 0, and goes up to atmInterface[Conf|Current]MaxSvccVpi. The argument for atmInterface[Conf|Current]MinSvccVci is a little less compelling, but went something like "there are PVC-like connections in the low end of the VCI range (eg. signalling and ILMI links), so it would be nice to collect all the PVCs at the low end of the VCI range. Hence, space reserved for SVCs starts at atmInterface[Conf|Current]MinSccVci, and goes up to atmInterface[Active|Current]MaxVciBits. 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 aa04546; 26 Feb 97 3:56 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa04945; 26 Feb 97 3:56 EST Received: from info.curtin.edu.au (root@info.curtin.edu.au [134.7.70.222]) by thumper.bellcore.com (8.8.5/8.8.5) with ESMTP id DAA06175 for ; Wed, 26 Feb 1997 03:23:04 -0500 (EST) Received: from atri.curtin.edu.au ([134.7.130.21]) by info.curtin.edu.au (8.8.5/8.8.5) with SMTP id QAA04969 for ; Wed, 26 Feb 1997 16:22:56 +0800 (WST) Received: from Josef.atri by atri.curtin.edu.au (4.1/ATRI-1.1) id AA19471; Wed, 26 Feb 97 16:22:04 WST Date: Wed, 26 Feb 97 16:22:04 WST From: Peter Jones Message-Id: <9702260822.AA19471@atri.curtin.edu.au> To: atommib@thumper.bellcore.com Subject: correlation to ILMI Hi There, Apologies if you have seen this already, I just haven't seen my own message back from the list yet. regards Peter Jones _______________________________________________________________________ Peter Jones. Australian Telecommunication Project Manager Research Institute (ATRI) .-_|\ Network Management Curtin Uni of Technology / \ Phone: +61 9 351 3581 Bentley WA, 6102. P_.-._/ Fax: +61 9 351 3244 Australia. o e-mail: peter@atri.curtin.edu.au _______________________________________________________________________ ----- Begin Included Message ----- From peter Mon Feb 24 10:59:31 1997 To: atommib@thumper.bellcore.com Subject: correlation to ILMI Cc: kaj@cc.bellcore.com, jn Content-Length: 1785 Hi There, I have a question for the list about the recent atm1ng draft and it's harmonisation with ILMI. Should add atmInterfaceCurrentMaxVpcs and atmInterfaceCurrentMaxVccs attributes be added? According to ILMI V4.0 - Sections 8.2.3.5 Maximum Number of VCCs and 8.2.3.6 Maximum Number of VPCs, the IME is supposed to negotiate about the maximum numbers of VPCs and VCCs allowed across the link in the same way the the number of active bits is negotiated. Since atm1ng-03 includes atmInterfaceMaxActiveVpiBits and atmInterfaceCurrentMaxVpiBits atmInterfaceMaxActiveVciBits and atmInterfaceCurrentMaxVciBit I think the maximum numbers of VPCs and VCCs have the same type of structure, i.e. atmInterfaceMaxVpcs and atmInterfaceCurrentMaxVpcs atmInterfaceMaxVccs and atmInterfaceCurrentMaxVccs I have already run this past Kaj. His reply was: > did you look at the revised supplemental mib that faye posted? > that should have the stuff you're asking for. if not can you > send something to the list? i want to make sure that we get > it right before we wrap up. > > kaj I have had a quick look at as posted recently and it does not seem to cover this. regards Peter Jones _______________________________________________________________________ Peter Jones. Australian Telecommunication Project Manager Research Institute (ATRI) .-_|\ Network Management Curtin Uni of Technology / \ Phone: +61 9 351 3581 Bentley WA, 6102. P_.-._/ Fax: +61 9 351 3244 Australia. o e-mail: peter@atri.curtin.edu.au _______________________________________________________________________ ----- End Included Message -----   Received: from cnri by ietf.org id aa07205; 26 Feb 97 5:24 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa06281; 26 Feb 97 5:24 EST Received: from ornet.ornet.co.il (ornet.co.il [194.90.140.5]) by thumper.bellcore.com (8.8.5/8.8.5) with ESMTP id EAA07151 for ; Wed, 26 Feb 1997 04:52:48 -0500 (EST) Received: from rafiki.ornet.co.il (rafiki.ornet.co.il [194.90.140.17]) by ornet.ornet.co.il (8.7.6/8.7.3) with ESMTP id LAA04024; Wed, 26 Feb 1997 11:52:39 +0200 (IST) From: David Melman Received: (from melman@localhost) by rafiki.ornet.co.il (8.7.6/8.7.3) id LAA25252; Wed, 26 Feb 1997 11:52:38 +0200 (IST) Date: Wed, 26 Feb 1997 11:52:38 +0200 (IST) Message-Id: <199702260952.LAA25252@rafiki.ornet.co.il> To: atommib@thumper.bellcore.com Subject: AToM MIB object VS ILMI object semantics Cc: igor@mailhost.ornet.co.il Hello. Do the AToM objects: atmInterfaceConfVpcs and atmInterfaceConfVccs have the same semantics as the ILMI MIB objects: atmfAtmLayerConfiguredVCCs and atmfAtmLayerConfiguredVPCs The ILMI refers only to "permanent" connections, and the AToM includes switched connections. Are they indeed differerent? Thanks in advance, David _________________________________________________________________________ David Melman ORNET Data Communications Tel: +972-4-9981314 Technologies Ltd. Fax: +972-4-9981315 A SIEMENS company email: melman@ornet.co.il smail: P.O.B 323 Carmiel 21613 Israel   Received: from cnri by ietf.org id aa04990; 27 Feb 97 0:42 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa02111; 27 Feb 97 0:42 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 AAA12639 for ; Thu, 27 Feb 1997 00:08:32 -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 VAA04548; Wed, 26 Feb 1997 21:08:00 -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 VAA10390; Wed, 26 Feb 1997 21:03:10 -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 VAA08667; Wed, 26 Feb 1997 21:07:28 -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 VAA27226; Wed, 26 Feb 1997 21:07:59 -0800 (PST) Received: by sutter.NSD.3Com.COM id AA14952 (5.65c/IDA-1.4.4-910730); Wed, 26 Feb 1997 21:07:27 -0800 Date: Wed, 26 Feb 1997 21:07:27 -0800 From: Faye Ly Message-Id: <199702270507.AA14952@sutter.NSD.3Com.COM> To: atommib@thumper.bellcore.com, stevebu@ca.newbridge.com Subject: Re: (Fwd) atmInterface[Conf|Current]MinSvccVci Cc: fayely@3com.com > Andrew Juniper wrote: > > > All, > > > > 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? > > I don't believe so, I think those objects were inadvertently removed from > the mib when the Vpi objects were changed. We still need > atmInterfaceConfMinSvccVci and atmInterfaceCurrentMinSvccVci. > Steve is right. I think I deleted the atmInterfaceConfMinSvccVci (and the rest of them) by mistake. They should be in the atmInterfaceExtTable along with the atmInterfaceConfMaxSvccVci ... I guess I need some more text in the section 6.3.13. Section 6.3.13 currently has an example of how the Min parameters work but no description for the Max. Steve, can you please provide us with an example for the Max parameters as well? Thanks. -faye fayely@3com.com (408)764-6576   Received: from cnri by ietf.org id aa24061; 28 Feb 97 13:08 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa15051; 28 Feb 97 13:08 EST Received: from ihgw1.lucent.com (ihgw1.lucent.com [207.19.48.1]) by thumper.bellcore.com (8.8.5/8.8.5) with SMTP id MAA03121 for ; Fri, 28 Feb 1997 12:35:34 -0500 (EST) From: dxie@mtgbcs.mt.lucent.com Received: from mtgbcs.mt.lucent.com by ihig1.firewall.lucent.com (SMI-8.6/EMS-L sol2) id LAA15595; Fri, 28 Feb 1997 11:45:13 -0600 Received: from mtpcs52-102 by mtgbcs.mt.lucent.com (5.0/EMS-L sol2) id AA22342; Fri, 28 Feb 1997 12:32:58 -0500 Message-Id: <970228123838.ZM2887@mtpcs52-102> Date: Fri, 28 Feb 1997 12:38:36 -0400 In-Reply-To: Steve Buchko "Re: (Fwd) atmInterface[Conf|Current]MinSvccVci" (Feb 25, 2:29pm) References: <199702251929.OAA22376@thor.ca.newbridge.com> X-Mailer: Z-Mail 4.0 (4.0.0 Aug 21 1995) To: atommib@thumper.bellcore.com Subject: currentMaxVpcc and currentMaxVccs Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Kaj: Are we going to add atmInterfaceCurrentMaxVpcc and atmInterfaceCurrentMaxVccs, as Peter Jones pointed out, before making the AToM draft to RFC? -- Dawn Xie dawnxie@lucent.com (908) 957-2066