Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00312; 10 Apr 95 3:52 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa00308; 10 Apr 95 3:52 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa01037; 10 Apr 95 3:52 EDT Received: from inet-tsb.toshiba.co.jp (inet-tsb.toshiba.co.jp [133.199.216.20]) by thumper.bellcore.com (8.6.9/8.6.10) with SMTP id CAA00653 for ; Mon, 10 Apr 1995 02:47:31 -0400 Received: from tis2.tis.toshiba.co.jp (tis2) by inet-tsb.toshiba.co.jp (5.67+1.6W/2.8Wb) id AA23921; Mon, 10 Apr 95 15:47:19 JST Received: from hino.toshiba.co.jp (hino-relay) by tis2.tis.toshiba.co.jp (5.67+1.6W/6.4J.6-R05) id AA12277; Mon, 10 Apr 95 15:48:34 JST Received: from hno89e05.atm.hino.toshiba.co.jp ([133.114.128.177]) by hino.toshiba.co.jp (5.67+1.6W/2.8Wb) id AA23236; Mon, 10 Apr 95 15:51:26 JST Received: by hno89e05.atm.hino.toshiba.co.jp (4.1/SMI-4.1) id AA29679; Mon, 10 Apr 95 15:46:09 JST Date: Mon, 10 Apr 95 15:46:09 JST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Tomohide KAWANO Message-Id: <9504100646.AA29679@hno89e05.atm.hino.toshiba.co.jp> To: atommib@thumper.bellcore.com Subject: subscribe Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Please subscribe me.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02995; 10 Apr 95 10:41 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02991; 10 Apr 95 10:41 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa06890; 10 Apr 95 10:41 EDT Received: from fore.com (relay.fore.com [169.144.1.1]) by thumper.bellcore.com (8.6.9/8.6.10) with ESMTP id KAA24455 for ; Mon, 10 Apr 1995 10:03:34 -0400 Received: from dolphin (dolphin.fore.com [169.144.1.16]) by fore.com (8.6.9/8.6.5) with SMTP id KAA07547 for ; Mon, 10 Apr 1995 10:01:42 -0400 Received: from shell.fore.com by dolphin (4.1/SMI-4.1) id AA02582; Mon, 10 Apr 95 10:03:31 EDT Received: from [198.29.27.14] (dummy-14-md) by shell.fore.com (4.1/SMI-4.1) id AA20748; Mon, 10 Apr 95 10:03:34 EDT X-Sender: rbibb@pophost.fore.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 10 Apr 1995 10:05:24 +0100 To: atommib@thumper.bellcore.com Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Richard Bibb Subject: unsubscribe Unsubscribe Richard E. Bibb TEL: (301) 564-4404 Federal Program Manager PAGE:(800) 719-1246 Navy and Air Force FAX: (301) 564-4408 FORE Systems 6500 Rock Spring Drive, Suite 444 rbibb@fore.com Bethesda, MD 20817   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06785; 13 Apr 95 14:12 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06781; 13 Apr 95 14:12 EDT Received: from [128.96.41.1] by CNRI.Reston.VA.US id aa12628; 13 Apr 95 14:12 EDT Received: from mail.bellcore.com (mail.bellcore.com [128.96.90.10]) by thumper.bellcore.com (8.6.9/8.6.10) with SMTP id NAA05425 for ; Thu, 13 Apr 1995 13:34:56 -0400 Received: from eve (eve.bellcore.com) by mail.bellcore.com (5.65c/2.1) id AA25785; Thu, 13 Apr 1995 13:26:10 -0400 Received: from by eve (4.1/4.7) id AB02673; Thu, 13 Apr 95 13:39:14 EDT Date: Thu, 13 Apr 95 13:39:14 EDT X-Station-Sent-From: eve.bellcore.com X-Sender: kaj@eve.bellcore.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: atommib@thumper.bellcore.com Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Kaj Tesink Subject: Draft - AToMMIB WG Danvers meeting report hi all, attached is the draft report of the Danvers meeting. in accordance with the secretariats guidelines the format avoids elaboration on all individual issues or the "john said/mary responded" format - instead i'll post the revised issues list to this mailing list. please look it over and comment if there's anything that you feel is missing. i plan to forward this to the secretariat by monday. kaj ------------------------------- AToMMIB WG The reactivated AToMMIB WG met two times during the Danvers meeting. The WG has a number of objectives: 1.To define at managed objects for ATM that address functions beyond those defined in RFC1695, e.g., for ATM SVCs. 2.To decide the maturity level of RFC1695 and 1595 and to assess whether these specifications should be advanced on the standards track. The Danvers meeting was used to review the first objective, and in particular the posted I-D . The second objective for now is best handled on the mailing list. Kaj will send out a call for implementation experience. In addition to the mailing list the Stockholm meeting can be used for a first review of the feedback. Note that RFC1595 may benefit from the review of the DS1/E1/DS3/E3 MIBs which is expected after the Stockholm meeting. The posted I-D is the result of efforts both in the ATMForum and on the mailing list. Host and network perspectives have now been combined in this document. The current draft was introduced by Fay Ly and Mike Noto. In addition, George Mouradian presented issues encountered in the ATM Forum NM SWG. The goal of the following discussion was to resolve issues that have been raised on the mailing list as well as additional issues raised during this meeting. Due to lack of time not all issues could be addressed. One conclusion was to create a separate document on textual conventions for ATM MIBs. This will be a 'living' document to be used by other ATM MIB specifications. A revised issues list will be posted that includes newly identified issues and the resolutions agreed upon during the meeting. The editors will revise the I-D accordingly and post the new version together with the new ATMMIBTC specification. _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ _/ _/ _/ Kaj Tesink _/ _/ Bellcore _/ _/ - Broadband Data Services & Consulting vmail (908) 758-5254 _/ _/ 331 Newman Springs Rd. email kaj@cc.bellcore.com _/ _/ Red Bank, NJ 07701 faxmail (908) 758-4196 _/ _/ _/ _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10843; 13 Apr 95 17:10 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10838; 13 Apr 95 17:10 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa16561; 13 Apr 95 17:10 EDT Received: from mail.bellcore.com (mail.bellcore.com [128.96.90.10]) by thumper.bellcore.com (8.6.9/8.6.10) with SMTP id QAA22654 for ; Thu, 13 Apr 1995 16:45:52 -0400 Received: from eve (eve.bellcore.com) by mail.bellcore.com (5.65c/2.1) id AA26658; Thu, 13 Apr 1995 16:37:07 -0400 Received: from by eve (4.1/4.7) id AB03944; Thu, 13 Apr 95 16:50:11 EDT Date: Thu, 13 Apr 95 16:50:11 EDT X-Station-Sent-From: eve.bellcore.com X-Sender: kaj@eve.bellcore.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: atommib@thumper.bellcore.com Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Kaj Tesink Subject: <18> atmVclExtTable & Call Forwarding <18> atmVclExtTable & Call Forwarding Issue: Does the address info represent the address where the call was initially intended for or the address where the call eventually ended up Proposal: for a number of reasons it seems to make sense that this should be the address where the call eventually ended up rather than the address where the call was initially intended for. - the initial address has very transient significance - you want to know who you're talking to in the tables with remote address info, rather than who you could have been talking to Any other views? kaj _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ _/ _/ _/ Kaj Tesink _/ _/ Bellcore _/ _/ - Broadband Data Services & Consulting vmail (908) 758-5254 _/ _/ 331 Newman Springs Rd. email kaj@cc.bellcore.com _/ _/ Red Bank, NJ 07701 faxmail (908) 758-4196 _/ _/ _/ _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11006; 13 Apr 95 17:14 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11002; 13 Apr 95 17:14 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa16723; 13 Apr 95 17:14 EDT Received: from mail.bellcore.com (mail.bellcore.com [128.96.90.10]) by thumper.bellcore.com (8.6.9/8.6.10) with SMTP id QAA22649 for ; Thu, 13 Apr 1995 16:45:48 -0400 Received: from eve (eve.bellcore.com) by mail.bellcore.com (5.65c/2.1) id AA26654; Thu, 13 Apr 1995 16:37:03 -0400 Received: from by eve (4.1/4.7) id AB03944; Thu, 13 Apr 95 16:50:06 EDT Date: Thu, 13 Apr 95 16:50:06 EDT X-Station-Sent-From: eve.bellcore.com X-Sender: kaj@eve.bellcore.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: atommib@thumper.bellcore.com Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Kaj Tesink Subject: Issues list on the Suppl.ATM MIB Hi, Here's the revised issues list taking into account the Danvers comments. Please correct me if I missed anything. If you care to comment on any particular issue please use Subject lines using the below headings to facilitate mail sorting, e.g., Subject: <1> ATM address type If there are additional issues to be discussed holler and I'll give it a kaj PS this list doesnot contain 1695 or 1595 issues. As per previous mail we can discuss those on the mailing list for now. ---------------------------------------- <1> ATM address type Issue: Should AtmAddress objects always be accompanied by an AtmAddressType object Conclusion: No, since the address type is also determined by the length of the atm address (?). Related to the resolution of <2>. <2> ATM address representation Issue: What is the appropriate SYNTAX of AtmAddress Conclusion: The TC/syntax should capture the cases of noAddress, e164, netPrefix, nsap, e.g., ATMAddress::=OCTET STRING (SIZE(0|8|13|20) with the 8 octet case encoded with BCD. The variable length prefix should have its own TC. Keith McCloghrie will draft. <3> ATM Subaddress treatment Issue: What are the end-end and local roles of the ATM Subaddress. The relevance is the question on a) relationship between ifPhysAddress, ifRcvAddrTable, atmAddress and atmSubaddress b) the need of representation of the ATM Subaddress in the remote/local address lookup table. State of the art in ATM standards efforts is fuzzy. Conclusion: Treat separate from the atmAddress, and not as extension. Should not be a problem in this MIB but may be an issue in MIB II. Can use syntax of AtmAddress. <4> Signalling Channel Bandwidth Issue: What is the appropriate atmTrafficDescriptorType for signaling channels Conclusion: This is a local issue - no need to specify <5> Connection Setup Failure counters Issue: This group contains 3 buckets a) is the bucket approach the right one? Alternatives: - a table with the last n failures - a table with the latest, timestamped, occurrence of each failure type b) is the distribution of failure types over the buckets useful Conclusion: Keep the three counter buckets unless mailing list concludes differently <6> Call Screening Issue: There are several ways how call screening could be setup wrt the action on screen failure (current text routes to a default number). Does this need to be mibbified now, and if so what is the correct feature description <7> Length atmIfAdminAddrTable Issue: The introductory text calls for a max length of this table of 16 entries. What is the point of a max length. Conclusion: Dont specify a max length <8> SSCOP parameters Issue: Is it useful from a manager perspective to include SSCOP objects, and, if so, are two two defined Counters sufficient. Conclusion: Keep them in as is. Health parameters instead of Counters? Jon Bosley will draft a proposal. <9> Per-connection counters (atmVclStatTable) Issue: Are per connection counters generally implementable. Discussion 2 years back concluded that they were not. Recent discussion argues in favor of them. There seems consensus on the usefulness of such a feature. However, since the feature doesnt scale very well, (e.g., large numbers of VCs in proxy situations) there is a question on whether this should be standardized, and if so, how: - Counters/VC in all circumstances - Counters/VC with up to n counters active at a time - Counters/VC for specific scenarios only - Rely on FTP to retrieve "accounting data" files (editors note: abuse of the conformance statement equates to options in disguise :-( Conclusion: Applies to both VPCs and SVCs. Not for accounting purposes. Keep these counters. Conformance statement will say: For systems that are supporting per VPC/VCC counters, these are the MIB objects that must be used. <10> UPC/NPC counters Issue: As per <9> Note that UPC/NPC counters could be useful for capacity planning and trouble isolation. Conclusion: Up to the mailing list <11> Indexing signaling entities Issue: What is the proper index clause for these tables given that multiple signaling channels may be used on a given interface. Currently: INDEX [ifIndex, atmInterfaceSigVpi, atmInterfaceSigVci] Should the value of ifIndex correspond to that of the ATM layer. Conclusion: All tables related to signaling should be indexed with INDEX [ifIndex, atmInterfaceSigVpi] All these tables should be combined into a single atmSvcTable: atmInterfaceSVCConfTable atmSSCOPTable atmUnsuptServTable atmSigLyrErrTable atmIfSigStatTable atmSubscrFeaturTable Add a column user/network/symmetric Text preceeding the actual MIB should explain the rationale and circumstances of the indexing. The atmIfAdminAddrTable should be indexed by [ifIndex, vpi, atmAddress] <12> Logs Issue: What about adding a log, e.g., for the latest n call clearings. See posting by jbs@vnet.ibm.com See also <5>. Conclusion: No log MIB. "MIB-triggered" log proposals invited. <13> Setup failure trap Issue: What about adding a setup failure trap that can be enables/disabled. Varbind list would correspond with the entry of <12> Conclusion: No failure traps <14> Address info redundancy Issue: Strictly speaking there is redundancy between the atmVclExtTable and the atmVclAddrtable since both tables provide the same info. However, by having both tables we avoid the need to retrieve a whole table in order to find a particular entry in some cases. Does the relative frequency of this need justify 2 tables? <15> AutoDiscovery over VP Issue: Since ILMI is approved to be used over NNI and also over VP, we defined at additional logical neighbor ( over VP ) objects that parallel the existing ones in 1695. With this addition, the NMS can discover the (logical) neighbor node over each VP and so on. Conclusion: Add sysOID, sysDescr (also in 1695) <16> Point-Multipoint Parties and ATOMMIB Issue: Make sure that the atmVclExtTable and the atmVclAddrTable handle pt/pt, pt/mpt and mpt/mpt connections And what about Endpoint References? <17> Tests Issue: MIB objects for tests such as loopback <18> atmVclExtTable & Call Forwarding Issue: Does the address info represent the address where the call was initially intended for or the address where the call eventually ended up <19> Subscription features Need/Definition Issue: Is this table really needed and are the definitions correct <20> Separate TC document Issue: Should all ATM MIB TCs be concentrated in a separate document Conclusion: Yes <21> Separation of PVC/SVC tables Issue: Should PVC and SVC info be combined in single tables or, because of their different nature, be kept in separate tables _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ _/ _/ _/ Kaj Tesink _/ _/ Bellcore _/ _/ - Broadband Data Services & Consulting vmail (908) 758-5254 _/ _/ 331 Newman Springs Rd. email kaj@cc.bellcore.com _/ _/ Red Bank, NJ 07701 faxmail (908) 758-4196 _/ _/ _/ _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14316; 13 Apr 95 21:07 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa14312; 13 Apr 95 21:07 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa21068; 13 Apr 95 21:07 EDT Received: from lobster.wellfleet.com (lobster.wellfleet.com [192.32.253.3]) by thumper.bellcore.com (8.6.9/8.6.10) with SMTP id UAA07721 for ; Thu, 13 Apr 1995 20:45:05 -0400 Received: from wellfleet (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA19597; Thu, 13 Apr 95 20:34:48 EDT Received: from zxcv.wellfleet by wellfleet (4.1/SMI-4.1) id AA28219; Thu, 13 Apr 95 20:39:33 EDT Date: Thu, 13 Apr 95 20:39:33 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Tom Colley Message-Id: <9504140039.AA28219@wellfleet> Received: by zxcv.wellfleet (4.1/SMI-4.1) id AA10872; Thu, 13 Apr 95 20:34:19 EDT To: Kaj Tesink Cc: atommib@thumper.bellcore.com Subject: Re: <18> atmVclExtTable & Call Forwarding In-Reply-To: References: On Thu, 13 April, Kaj Tesink (kaj@cc.bellcore.com) wrote: > <18> atmVclExtTable & Call Forwarding > > Issue: Does the address info represent the address > where the call was initially intended for or > the address where the call eventually ended up (I can't recall seeing call forwarding discussed in UNI 3.0 or 3.1, is it documented somewhere?) How does the originator of a call know that the call has been forwarded, and how does it obtain the address the call was forwarded to? Tom   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10260; 17 Apr 95 19:35 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10256; 17 Apr 95 19:35 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa05029; 17 Apr 95 19:35 EDT Received: from mail.bellcore.com (mail.bellcore.com [128.96.90.10]) by thumper.bellcore.com (8.6.9/8.6.10) with SMTP id TAA15376 for ; Mon, 17 Apr 1995 19:05:57 -0400 Received: from eve (eve.bellcore.com) by mail.bellcore.com (5.65c/2.1) id AA06299; Mon, 17 Apr 1995 18:57:10 -0400 Received: from [128.96.82.154] (nv-ktesink.cc.bellcore.com) by eve (4.1/4.7) id AA20135; Mon, 17 Apr 95 19:10:17 EDT Date: Mon, 17 Apr 95 19:10:15 EDT X-Station-Sent-From: eve.bellcore.com X-Sender: kaj@eve.bellcore.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: minutes@CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Kaj Tesink Subject: AToMMIB WG Danvers meeting report Cc: atommib@thumper.bellcore.com, dck2@eve.bellcore.com hi Debra, here are the minutes of the AToMMIB WG meeting in Danvers. kaj ------------------------------- AToMMIB WG The reactivated AToMMIB WG met two times during the Danvers meeting. The WG has a number of objectives: 1.To define at managed objects for ATM that address functions beyond those defined in RFC1695, e.g., for ATM SVCs. 2.To decide the maturity level of RFC1695 and 1595 and to assess whether these specifications should be advanced on the standards track. The Danvers meeting was used to review the first objective, and in particular the posted I-D . The second objective for now is best handled on the mailing list. Kaj will send out a call for implementation experience. In addition to the mailing list the Stockholm meeting can be used for a first review of the feedback. Note that RFC1595 may benefit from the review of the DS1/E1/DS3/E3 MIBs which is expected after the Stockholm meeting. The posted I-D is the result of efforts both in the ATMForum and on the mailing list. Host and network perspectives have now been combined in this document. The current draft was introduced by Fay Ly and Mike Noto. In addition, George Mouradian presented issues encountered in the ATM Forum NM SWG. The goal of the following discussion was to resolve issues that have been raised on the mailing list as well as additional issues raised during this meeting. Due to lack of time not all issues could be addressed. One conclusion was to create a separate document on textual conventions for ATM MIBs. This will be a 'living' document to be used by other ATM MIB specifications. A revised issues list will be posted that includes newly identified issues and the resolutions agreed upon during the meeting. The editors will revise the I-D accordingly and post the new version together with the new ATMMIBTC specification. _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ _/ _/ _/ Kaj Tesink _/ _/ Bellcore _/ _/ - Broadband Data Services & Consulting vmail (908) 758-5254 _/ _/ 331 Newman Springs Rd. email kaj@cc.bellcore.com _/ _/ Red Bank, NJ 07701 faxmail (908) 758-4196 _/ _/ _/ _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ _/ _/ _/ Kaj Tesink _/ _/ Bellcore _/ _/ - Broadband Data Services & Consulting vmail (908) 758-5254 _/ _/ 331 Newman Springs Rd. email kaj@cc.bellcore.com _/ _/ Red Bank, NJ 07701 faxmail (908) 758-4196 _/ _/ _/ _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12006; 19 Apr 95 18:56 EDT Received: from [132.151.1.1] by IETF.CNRI.Reston.VA.US id aa11998; 19 Apr 95 18:56 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa16677; 19 Apr 95 18:56 EDT Received: from nbkanata.newbridge.com (Newbridge.COM [192.75.23.5]) by thumper.bellcore.com (8.6.9/8.6.10) with SMTP id SAA07179 for ; Wed, 19 Apr 1995 18:27:36 -0400 Received: from thor.Newbridge.com by nbkanata.newbridge.com (4.1/SMI-4.1) id AA22696; Wed, 19 Apr 95 18:27:20 EDT Received: from spanky.newbridge by thor.Newbridge.com (4.1/SMI-4.0) id AA01730; Wed, 19 Apr 95 18:27:30 EDT Date: Wed, 19 Apr 95 18:27:30 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Jonathan Bosloy Message-Id: <9504192227.AA01730@thor.Newbridge.com> To: atommib@thumper.bellcore.com Subject: Re: <18> atmVclExtTable & Call Forwarding Cc: jonathan@newbridge.com On Thu, 13 April, Kaj Tesink (kaj@cc.bellcore.com) wrote: > > <18> atmVclExtTable & Call Forwarding > > Issue: Does the address info represent the address > where the call was initially intended for or > the address where the call eventually ended up > > Proposal: for a number of reasons it seems to make sense > that this should be the address where the call eventually ended up > rather than the address where the call was initially intended for. > - the initial address has very transient significance > - you want to know who you're talking to in the tables with > remote address info, rather than who you could have been talking to > I Think that the remote address should reflect who was called (i.e. the called party number). For example, say I call "addr A", but I end up connected to "addr B" for a reason such as call forwarding. I want to see the SVC as going to "addr A", since "addr B" may have no significance to me (i.e. it may be a location I know nothing about, such as a backup site or an overflow site for the destination I am calling). There is a supplementary service called connected line presentation. There are two IEs, connected number, and connected subaddress, which can be sent back in the CONNECT message (from the actual destination) and presented to the calling party. These IEs are NOT part of Q.2931 and ATM Forum UNI 3.1. Thus, I suggest we ignore this for now. In the future, we may want the connected address to appear in the MIB, in addition to the local address and the remote address. ____________________________________________________________________________ Jonathan Bosloy, jonathan@newbridge.com Ph: +1 613 591-3600 Newbridge Networks 600 March Rd Kanata ON Canada K2K 2E6 FAX:+1 613 599-3609   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa23857; 20 Apr 95 2:43 EDT Received: from [132.151.1.1] by IETF.CNRI.Reston.VA.US id aa23853; 20 Apr 95 2:43 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa23897; 20 Apr 95 2:43 EDT Received: from foxhound.cisco.com (foxhound.cisco.com [171.69.1.171]) by thumper.bellcore.com (8.6.9/8.6.10) with ESMTP id CAA02385 for ; Thu, 20 Apr 1995 02:14:32 -0400 Received: (kzm@localhost) by foxhound.cisco.com (8.6.8+c/8.6.5) id XAA14087; Wed, 19 Apr 1995 23:14:03 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Keith McCloghrie Message-Id: <199504200614.XAA14087@foxhound.cisco.com> Subject: Re: <18> atmVclExtTable & Call Forwarding To: Jonathan Bosloy Date: Wed, 19 Apr 95 23:14:02 PDT Cc: atommib@thumper.bellcore.com, jonathan@newbridge.com In-Reply-To: <9504192227.AA01730@thor.Newbridge.com>; from "Jonathan Bosloy" at Apr 19, 95 6:27 pm X-Mailer: ELM [version 2.3 PL11] > > <18> atmVclExtTable & Call Forwarding > > > > Issue: Does the address info represent the address > > where the call was initially intended for or > > the address where the call eventually ended up > > > > Proposal: for a number of reasons it seems to make sense > > that this should be the address where the call eventually ended up > > rather than the address where the call was initially intended for. > > - the initial address has very transient significance > > - you want to know who you're talking to in the tables with > > remote address info, rather than who you could have been talking to > > I Think that the remote address should reflect who was called (i.e. > the called party number). For example, say I call "addr A", but I end up > connected to "addr B" for a reason such as call forwarding. I want to > see the SVC as going to "addr A", since "addr B" may have no significance > to me (i.e. it may be a location I know nothing about, such as a backup > site or an overflow site for the destination I am calling). I tend to agree. My example would be future use of a ATM Multicast/Group address as the called party. I think it's useful to know that the call was setup to the group address, and it's not clear to me whether the calling party even knows what the connected address is. Keith.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12407; 23 Apr 95 0:25 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa12403; 23 Apr 95 0:25 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa16475; 23 Apr 95 0:25 EDT Received: from boole.std.caci.com (boole.std.caci.com [192.190.177.5]) by thumper.bellcore.com (8.6.9/8.6.10) with ESMTP id XAA14443 for ; Sat, 22 Apr 1995 23:48:27 -0400 Received: by boole.std.caci.com (8.6.9/1.34) id WAA04345; Sat, 22 Apr 1995 22:31:03 -0400 Date: Sat, 22 Apr 1995 22:31:03 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: hnguyen Message-Id: <199504230231.WAA04345@boole.std.caci.com> To: atommib@thumper.bellcore.com Subject: subscribe hnguyen@boole.std.caci.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11704; 25 Apr 95 18:12 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11700; 25 Apr 95 18:12 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa21753; 25 Apr 95 18:12 EDT Received: from atmsys.com (isthmus.atmsys.com [198.211.211.2]) by thumper.bellcore.com (8.6.9/8.6.10) with SMTP id RAA18209 for ; Tue, 25 Apr 1995 17:37:13 -0400 Received: from beauty.atmsys.com ([144.10.1.2]) by atmsys.com (4.1/SMI-4.1/ATMsys) id AA26417; Tue, 25 Apr 95 14:36:23 PDT Received: from atmsys.com by atmsys.com (4.1/SMI-4.1/ATMsys) id AA17540; Tue, 25 Apr 95 14:36:22 PDT Received: by shumba.atmsys.com (5.x/SMI-SVR4) id AA14699; Tue, 25 Apr 1995 14:36:19 -0700 Date: Tue, 25 Apr 1995 14:36:19 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Ross Schibler Message-Id: <9504252136.AA14699@shumba.atmsys.com> To: atommib@thumper.bellcore.com, kaj@cc.bellcore.com Subject: <21> Separation of PVC/SVC tables X-Sun-Charset: US-ASCII > From kaj@cc.bellcore.com Thu Apr 13 15:20 PDT 1995 > Here's the revised issues list taking into account the > Danvers comments. ... > <21> Separation of PVC/SVC tables > > Issue: Should PVC and SVC info be combined in single tables > or, because of their different nature, be kept in > separate tables > I think PVC/PVP information should be kept in a separate table from SVC infromation. My reasons are as follows: 1) I believe that some NMS applications will be managing PVCs/PVPs, while different applications will be looking at SVCs. I think these applications would want the information orgainized slightly differently. For example, it would be convenient for those applications if a GetNext returned the next SVC or next PVC, as appropriate, rather than just the next VC. 2) The existing RFC-1695 seems oriented for PVCs and PVPs, and uses a traffic descriptor table to reduce storage space for common traffic types. In the SVC world, calls are instantiated using a wide variety of individually traffic parameters, which do not map into the common traffic descriptor table. The parameters would probably have to be stored on a per-call basis because of the wide variety values for of traffic description parameters. A couple of people who were both at the Danvers and Denver (ATM Forum / NM) meetings expressed similar opinions, but I'll let them chime in themselves..... Ross   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13042; 25 Apr 95 20:24 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa13038; 25 Apr 95 20:24 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa23953; 25 Apr 95 20:24 EDT Received: from lightning.synoptics.com (lightning.synoptics.com [134.177.3.18]) by thumper.bellcore.com (8.6.9/8.6.10) with SMTP id TAA26697 for ; Tue, 25 Apr 1995 19:58:21 -0400 Received: from BayNetworks.COM ([134.177.1.95]) by lightning.synoptics.com (4.1/SMI-4.1) id AA20763; Tue, 25 Apr 95 16:57:07 PDT Received: from mystical (mystical.synoptics.com) by BayNetworks.COM (4.1/SMI-4.1) id AA02350; Tue, 25 Apr 95 16:55:07 PDT Received: by mystical (4.1/2.0N) id AA25250; Tue, 25 Apr 95 16:55:06 PDT Message-Id: <9504252355.AA25250@mystical> Date: Tue, 25 Apr 95 16:55:06 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Faye Ly To: ross@atmsys.com Subject: Re: <21> Separation of PVC/SVC tables Cc: atommib@thumper.bellcore.com Ross, I am not really against your proposal, but I think there is always the cons we need to examine also: 1) First of all we have more tables. PVC, SVC, PVP and SVP. This might be a problem when Network Manager is trying to retrieve all VCs (for all types) associated with a certain entity. 2) All these tables have the same information in it except the RowStatus used for creation and deletion. And what about current implementation? For thoes who already put all VCs into one big table now have the trouble of converting all their getnext to be done by types also! And not to mention the size of the MIB will be even bigger! -faye   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09900; 26 Apr 95 15:33 EDT Received: from [132.151.1.1] by IETF.CNRI.Reston.VA.US id aa09896; 26 Apr 95 15:33 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa12858; 26 Apr 95 15:33 EDT Received: from mail.bellcore.com (mail.bellcore.com [128.96.90.10]) by thumper.bellcore.com (8.6.9/8.6.10) with SMTP id OAA00864 for ; Wed, 26 Apr 1995 14:51:38 -0400 Received: from eve (eve.bellcore.com) by mail.bellcore.com (5.65c/2.1) id AA19598; Wed, 26 Apr 1995 14:42:38 -0400 Received: from [128.96.82.154] (nv-ktesink.cc.bellcore.com) by eve (4.1/4.7) id AA01588; Wed, 26 Apr 95 14:55:47 EDT Date: Wed, 26 Apr 95 14:55:46 EDT X-Station-Sent-From: eve.bellcore.com X-Sender: kaj@eve.bellcore.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: atommib@thumper.bellcore.com Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Kaj Tesink Subject: Removed from atommib list The following entries have been removed from the list since these folks apparently left without leaving a forwarding address. If you know any of the affected people, please let them know. piergi@teculx.TECSIEL.IT dxt@fns.com groucho!jimmy@uu4.psi.com (Jimmy Tu) danny_propp@nicecom.nice.com MIKI@nicecom.nice.com Dan Frommer   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09912; 26 Apr 95 15:33 EDT Received: from [132.151.1.1] by IETF.CNRI.Reston.VA.US id aa09908; 26 Apr 95 15:33 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa12863; 26 Apr 95 15:33 EDT Received: from mail.bellcore.com (mail.bellcore.com [128.96.90.10]) by thumper.bellcore.com (8.6.9/8.6.10) with SMTP id OAA00870 for ; Wed, 26 Apr 1995 14:51:47 -0400 Received: from eve (eve.bellcore.com) by mail.bellcore.com (5.65c/2.1) id AA19606; Wed, 26 Apr 1995 14:42:46 -0400 Received: from by eve (4.1/4.7) id AB01588; Wed, 26 Apr 95 14:56:00 EDT Date: Wed, 26 Apr 95 14:56:00 EDT X-Station-Sent-From: eve.bellcore.com X-Sender: kaj@eve.bellcore.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: atommib@thumper.bellcore.com Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Kaj Tesink Subject: Re: <19> Subscription features Need/Definition howdy, i checked on the existence of mature specs on these respective features, and couldnt find any in the ATMF or ITU. so as per danvers things like call screening are inappropriate to mibbify right now. however, on the issue of whether Information Elements such as Clg/Cld Subaddress, High/Low Layer info etc are supported I ran into a dilemma: - these are user options because you donot always need them - at the same time not all switches or networks may support transfering these things. as jon mentioned, some carriers may not support them or charge separately for it (... such is life...) in my mind this means that we need these objects that simply say whether transfer is supported or not, in order to facilitate trouble isolation in cases where info gets lost. i guess we can get rid of the language that talks about subscription and just keep the enabled/disabled part. a last dilemma: we have currently also a Preferred Carrier object in the MIB. similarly as above, this hasnt been stabelized either, although a Transit Network IE has been defined (without procedures for its use). following the danvers discussion this object should therefore also be removed, although its fairly obvious that in intercarrier situation you'd need this thing. any strong feelings on this? kaj _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ _/ _/ _/ Kaj Tesink _/ _/ Bellcore _/ _/ - Broadband Data Services & Consulting vmail (908) 758-5254 _/ _/ 331 Newman Springs Rd. email kaj@cc.bellcore.com _/ _/ Red Bank, NJ 07701 faxmail (908) 758-4196 _/ _/ _/ _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09923; 26 Apr 95 15:33 EDT Received: from [132.151.1.1] by IETF.CNRI.Reston.VA.US id aa09919; 26 Apr 95 15:33 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa12868; 26 Apr 95 15:33 EDT Received: from mail.bellcore.com (mail.bellcore.com [128.96.90.10]) by thumper.bellcore.com (8.6.9/8.6.10) with SMTP id OAA00879 for ; Wed, 26 Apr 1995 14:51:52 -0400 Received: from eve (eve.bellcore.com) by mail.bellcore.com (5.65c/2.1) id AA19610; Wed, 26 Apr 1995 14:43:00 -0400 Received: from by eve (4.1/4.7) id AB01588; Wed, 26 Apr 95 14:56:14 EDT Date: Wed, 26 Apr 95 14:56:14 EDT X-Station-Sent-From: eve.bellcore.com X-Sender: kaj@eve.bellcore.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: atommib@thumper.bellcore.com Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Kaj Tesink Subject: Re: <21> Separation of PVC/SVC tables I have a similar view as Faye. We have to be careful that we dont upset existing implementations and/or that we dont introduce more tables for relatively rare applications. The key point is here how the SVCs and PVCs are sorted in the respective tables. Currently the Pvc and SVC entries are mixed; the tables are organized per interface. This is useful for some applications, e.g., what/how many VCs are there running on each i/f. Thus, in order to find out about SVCs-only you'll have to retrieve the whole table; a burden indeed. But some questions to ask are: - what are the applications that use the SVC-only request - how frequent is this table retrieval typically needed - how big is the table typically - what is the typical ratio between SVCs and PVCs It seems that we should only change these tables if - this application is used frequently - the table is usually large - and, if for example the SVC application is the dominant one, a table change would not be justified if the table is dominated by SVCs anyway kaj At 11:55 PM 4/25/95, Faye Ly wrote: >Ross, > >I am not really against your proposal, but I think there is always >the cons we need to examine also: > >1) First of all we have more tables. PVC, SVC, PVP and SVP. This >might be a problem when Network Manager is trying to retrieve all >VCs (for all types) associated with a certain entity. > >2) All these tables have the same information in it except the RowStatus >used for creation and deletion. And what about current implementation? >For thoes who already put all VCs into one big table now have the >trouble of converting all their getnext to be done by types also! >And not to mention the size of the MIB will be even bigger! > >-faye At 9:36 PM 4/25/95, Ross Schibler wrote: >> From kaj@cc.bellcore.com Thu Apr 13 15:20 PDT 1995 >> Here's the revised issues list taking into account the >> Danvers comments. >... >> <21> Separation of PVC/SVC tables >> >> Issue: Should PVC and SVC info be combined in single tables >> or, because of their different nature, be kept in >> separate tables >> > >I think PVC/PVP information should be kept in a separate table from >SVC infromation. My reasons are as follows: > >1) I believe that some NMS applications will be managing PVCs/PVPs, >while different applications will be looking at SVCs. I think these >applications would want the information orgainized slightly >differently. For example, it would be convenient for those applications >if a GetNext returned the next SVC or next PVC, as appropriate, rather >than just the next VC. > >2) The existing RFC-1695 seems oriented for PVCs and PVPs, and >uses a traffic descriptor table to reduce storage space for common >traffic types. In the SVC world, calls are instantiated using a wide >variety of individually traffic parameters, which do not map into the >common traffic descriptor table. The parameters would probably have to >be stored on a per-call basis because of the wide variety values for of >traffic description parameters. > >A couple of people who were both at the Danvers and Denver (ATM >Forum / NM) meetings expressed similar opinions, but I'll let them chime in >themselves..... > >Ross _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ _/ _/ _/ Kaj Tesink _/ _/ Bellcore _/ _/ - Broadband Data Services & Consulting vmail (908) 758-5254 _/ _/ 331 Newman Springs Rd. email kaj@cc.bellcore.com _/ _/ Red Bank, NJ 07701 faxmail (908) 758-4196 _/ _/ _/ _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11220; 26 Apr 95 17:00 EDT Received: from [132.151.1.1] by IETF.CNRI.Reston.VA.US id aa11215; 26 Apr 95 17:00 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa14389; 26 Apr 95 17:00 EDT Received: from lightning.synoptics.com (lightning.synoptics.com [134.177.3.18]) by thumper.bellcore.com (8.6.9/8.6.10) with SMTP id QAA09801 for ; Wed, 26 Apr 1995 16:24:13 -0400 Received: from BayNetworks.COM ([134.177.1.95]) by lightning.synoptics.com (4.1/SMI-4.1) id AA28527; Wed, 26 Apr 95 13:23:02 PDT Received: from milliways (milliways-sbf0.synoptics.com) by BayNetworks.COM (4.1/SMI-4.1) id AA16317; Wed, 26 Apr 95 13:21:16 PDT Received: by milliways (4.1/2.0N) id AA02505; Wed, 26 Apr 95 13:16:38 PDT Message-Id: <9504262016.AA02505@milliways> Date: Wed, 26 Apr 95 13:16:38 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Andrew Smith To: atommib@thumper.bellcore.com Subject: Re: <21> Separation of PVC/SVC tables > Date: Wed, 26 Apr 95 14:56:14 EDT > To: atommib@thumper.bellcore.com > From: kaj@cc.bellcore.com (Kaj Tesink) > Subject: Re: <21> Separation of PVC/SVC tables Kaj, ... > But some questions to ask are: Some data points with our NMS application hats on (as opposed to our Agent implementor hats): > - what are the applications that use the SVC-only request? Can't think of any. > - how frequent is this table retrieval typically needed? Very infrequent for the whole table. Needs to be efficient for individual PVC/SVC (don't care about which type) lookups. > - how big is the table typically? PVCs: small, SVCs: 1000s > - what is the typical ratio between SVCs and PVCs? Usually 100%:0% or 0%:100%. Only occasionally is there likely to be a mixture. Andrew & Faye ******************************************************************************** Andrew Smith TEL: +1 408 764 1574 Technology Synergy Unit FAX: +1 408 988 5525 Bay Networks, Inc. E-m: asmith@baynetworks.com Santa Clara, CA ********************************************************************************   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06104; 27 Apr 95 13:38 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06100; 27 Apr 95 13:38 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa10426; 27 Apr 95 13:38 EDT Received: from inet-gw-2.pa.dec.com (inet-gw-2.pa.dec.com [16.1.0.23]) by thumper.bellcore.com (8.6.9/8.6.10) with SMTP id NAA23475 for ; Thu, 27 Apr 1995 13:03:39 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: romanov@nacto.lkg.dec.com Received: from nacto1.nacto.lkg.dec.com by inet-gw-2.pa.dec.com (5.65/24Feb95) id AA09188; Thu, 27 Apr 95 09:59:48 -0700 Received: from kalvi.nacto.lkg.dec.com by nacto1.nacto.lkg.dec.com with SMTP id AA26503; Thu, 27 Apr 1995 12:59:36 -0400 Received: by kalvi.nacto.lkg.dec.com (5.65/4.7) id AA21454; Thu, 27 Apr 1995 12:59:37 -0400 Message-Id: <9504271659.AA21454@kalvi.nacto.lkg.dec.com> Subject: Re: <21> Separation of PVC/SVC tables To: Andrew Smith Date: Thu, 27 Apr 1995 12:59:36 -0400 (EDT) Cc: atommib@thumper.bellcore.com In-Reply-To: <9504262016.AA02505@milliways> from "Andrew Smith" at Apr 26, 95 01:16:38 pm X-Mailer: ELM [version 2.4 PL20] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1290 > > ... > > > But some questions to ask are: > Some data points with our NMS application hats on (as opposed to > our Agent implementor hats): > > > - what are the applications that use the SVC-only request? > Can't think of any. However, there is going to be a lot of the applications which do care about PVCs only. Especially when we are talking about SETs. It seems to me that SETs on SVC entries will be performed very seldom. > > - how frequent is this table retrieval typically needed? > Very infrequent for the whole table. Needs to be efficient for individual > PVC/SVC (don't care about which type) lookups. > > > - how big is the table typically? > PVCs: small, SVCs: 1000s One more reason for separation. IMHO, PVCs will be managed primarily through SNMP and SVCs through signalling. One more aspect is assigning unique CrossConnectID to SVCs. There is no problems do this in case of PVCs. In case of PVCs it can be relatively slow process and there will be no problem with single central piece of code administering CrossConnect assingments. At the same time SVCs has to be set up fast. Naturally, it is convinient to distribute SVC setup and then centralized management of CrossConnectIDs can be a bottleneck. > Andrew Smith TEL: +1 408 764 1574 Aleksey   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10378; 27 Apr 95 17:07 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10374; 27 Apr 95 17:07 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa14934; 27 Apr 95 17:07 EDT Received: from lightning.synoptics.com (lightning.synoptics.com [134.177.3.18]) by thumper.bellcore.com (8.6.9/8.6.10) with SMTP id QAA10814 for ; Thu, 27 Apr 1995 16:38:28 -0400 Received: from BayNetworks.COM ([134.177.1.95]) by lightning.synoptics.com (4.1/SMI-4.1) id AA08539; Thu, 27 Apr 95 13:37:12 PDT Received: from mystical (mystical.synoptics.com) by BayNetworks.COM (4.1/SMI-4.1) id AA04699; Thu, 27 Apr 95 13:35:16 PDT Received: by mystical (4.1/2.0N) id AA26000; Thu, 27 Apr 95 13:35:15 PDT Message-Id: <9504272035.AA26000@mystical> Date: Thu, 27 Apr 95 13:35:15 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Faye Ly To: atommib@thumper.bellcore.com Subject: Signaling Parameters in ATM MIBs Content-Type: X-sun-attachment ---------- X-Sun-Data-Type: text X-Sun-Data-Description: text X-Sun-Data-Name: text X-Sun-Content-Lines: 152 In the ATM MIB WG in Danvers, James (NewBridge) proposed another way of dealing with the signaling parameters as opposed to the current proposal which is done in two tables: atmSigDescrParamTable in supplemental MIB and atmTrafficDescrParamTable in RFC 1695. I thought that was a good idea since it first consolidates these two tables and second provides flexibility for future expansion such as UNI 4.0. It basically puts all signaling parameters in an OID tree. New signaling parameters can be registered as soon as they are defined. The data of the signaling parameters are stored in a separate table which has the tuple of { a straight numerical index, OID of the signaling parameter, value or data associated with the signaling parameter }. The signaling of a VC is specified by selecting the entries from this table which is similar to how it works now. I was torn on the decision of whether to include the TrafficDescriptor defined in RFC 1695 in this table or not! Only because some people out there might have implemented this table already? But I decided to include them in the proposal anyway and we can always take them out if there is any objection. Any way, I took the liberty to write the idea up: -- Registration for all signaling parameters sigParamTypeVal OBJECT IDENTIFIER ::= { ATM2-MIB ?? } -- ATM Adaptation Layer Parameters sigAalTypeVal OBJECT IDENTIFIER ::= { sigParamTypeVal 1 } sigAalTypeType OBJECT IDENTIFIER ::= { sigAalTypeVal 1 } sigAalTypeMode OBJECT IDENTIFIER ::= { sigAalTypeVal 2 } sigAalTypeSscsType OBJECT IDENTIFIER ::= { sigAalTypeVal 3 } -- ATM Traffic Descriptor sigTrafficDescrVal OBJECT IDENTIFIER ::= { sigParamTypeVal 2 } sigTrafForwardPeakCellRate OBJECT IDENTIFIER ::= { sigTrafficDescrVal 1 } sigTrafBackwardPeakCellRate OBJECT IDENTIFIER ::= { sigTrafficDescrVal 2 } ... and so on untill all parameters are described in this tree -- ATM Signaling Parameter Table atmSigParamTable OBJECT-TYPE SYNTAX SEQUENCE OF AtmSigParamEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table contains signaling capabilities of VCLs." ::= { ?? } atmSigParamEntry OBJECT-TYPE SYNTAX AtmSigParamEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry in this table represents a single signaling capabilities that can be applied to a VCL. Multiple entries in this table combined can be used to describe the signaling capabilities of a single VCL." INDEX { atmSigParamIndex, atmSigParamValueIndex } ::= { atmSigParamTable 1 } AtmSigParamEntry ::= SEQUENCE { atmSigParamIndex INTEGER, atmSigParamValueIndex INTEGER, atmSigParamType OBJECT IDENTIFIER, atmSigParamValue OCTET STRING, atmSigParamRowStatus RowStatus } atmSigParamIndex OBJECT-TYPE SYNTAX INTEGER MAX-ACCESS NOT-ACCESSIBLE STATUS current DESCRIPTION "The value of this object represents a set of signaling parameters that can be applied to a single or a set of VCLs. Multiple rows in this table can have the same value." ::= { atmSigParamEntry 1 } atmSigParamValueIndex OBJECT-TYPE SYNTAX INTEGER MAX-ACCESS NOT-ACCESSIBLE STATUS current DESCRIPTION "The value of this object uniquely identifies a single signaling parameter. No two rows in this table can have the same value." ::= { atmSigParamEntry 2 } atmSigParamType OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-create STATUS current DESCRIPTION "The type of the signaling parameter this entry is describing. The signaling parameters are defined under atmSigParamVal." ::= { atmSigParamEntry 3 } atmSigParamValue OBJECT-TYPE SYNTAX OCTET STRING (SIZE(??)) MAX-ACCESS read-create STATUS current DESCRIPTION "The data associated with the signaling parameter. for example, the AAL type (AAL 3,4 or AAL 5) for the sigAalTypeType." ::= { atmSigParamEntry 4 } atmSigParamRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The usual stuff." ::= { atmSigParamEntry 5 } The atmVclTable and atmVclExtTable will have to be modified to use the atmSigParamIndex to select a set of parameters associated with the VCL. Faye Ly (faye@baynetworks.com) James Watt (NewBridge) ---------- X-Sun-Data-Type: default X-Sun-Data-Description: default X-Sun-Data-Name: sigparam.comments X-Sun-Content-Lines: 154 In the ATM MIB WG in Danvers, James (NewBridge) proposed another way of dealing with the signaling parameters as opposed to the current proposal which is done in two tables: atmSigDescrParamTable in supplemental MIB and atmTrafficDescrParamTable in RFC 1695. I thought that was a good idea since it first consolidates these two tables and second provides flexibility for future expansion such as UNI 4.0. It basically puts all signaling parameters in an OID tree. New signaling parameters can be registered as soon as they are defined. The data of the signaling parameters are stored in a separate table which has the tuple of { a straight numerical index, OID of the signaling parameter, value or data associated with the signaling parameter }. The signaling of a VC is specified by selecting the entries from this table which is similar to how it works now. I was torn on the decision of whether to include the TrafficDescriptor defined in RFC 1695 in this table or not! Only because some people out there might have implemented this table already? But I decided to include them in the proposal anyway and we can always take them out if there is any objection. Any way, I took the liberty to write the idea up: -- Registration for all signaling parameters sigParamTypeVal OBJECT IDENTIFIER ::= { ATM2-MIB ?? } -- ATM Adaptation Layer Parameters sigAalTypeVal OBJECT IDENTIFIER ::= { sigParamTypeVal 1 } sigAalTypeType OBJECT IDENTIFIER ::= { sigAalTypeVal 1 } sigAalTypeMode OBJECT IDENTIFIER ::= { sigAalTypeVal 2 } sigAalTypeSscsType OBJECT IDENTIFIER ::= { sigAalTypeVal 3 } -- ATM Traffic Descriptor sigTrafficDescrVal OBJECT IDENTIFIER ::= { sigParamTypeVal 2 } sigTrafForwardPeakCellRate OBJECT IDENTIFIER ::= { sigTrafficDescrVal 1 } sigTrafBackwardPeakCellRate OBJECT IDENTIFIER ::= { sigTrafficDescrVal 2 } ... and so on untill all parameters are described in this tree -- ATM Signaling Parameter Table atmSigParamTable OBJECT-TYPE SYNTAX SEQUENCE OF AtmSigParamEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table contains signaling capabilities of VCLs." ::= { ?? } atmSigParamEntry OBJECT-TYPE SYNTAX AtmSigParamEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry in this table represents a single signaling capabilities that can be applied to a VCL. Multiple entries in this table combined can be used to describe the signaling capabilities of a single VCL." INDEX { atmSigParamIndex, atmSigParamValueIndex } ::= { atmSigParamTable 1 } AtmSigParamEntry ::= SEQUENCE { atmSigParamIndex INTEGER, atmSigParamValueIndex INTEGER, atmSigParamType OBJECT IDENTIFIER, atmSigParamValue OCTET STRING, atmSigParamRowStatus RowStatus } atmSigParamIndex OBJECT-TYPE SYNTAX INTEGER MAX-ACCESS NOT-ACCESSIBLE STATUS current DESCRIPTION "The value of this object represents a set of signaling parameters that can be applied to a single or a set of VCLs. Multiple rows in this table can have the same value." ::= { atmSigParamEntry 1 } atmSigParamValueIndex OBJECT-TYPE SYNTAX INTEGER MAX-ACCESS NOT-ACCESSIBLE STATUS current DESCRIPTION "The value of this object uniquely identifies a single signaling parameter. No two rows in this table can have the same value." ::= { atmSigParamEntry 2 } atmSigParamType OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-create STATUS current DESCRIPTION "The type of the signaling parameter this entry is describing. The signaling parameters are defined under atmSigParamVal." ::= { atmSigParamEntry 3 } atmSigParamValue OBJECT-TYPE SYNTAX OCTET STRING (SIZE(??)) MAX-ACCESS read-create STATUS current DESCRIPTION "The data associated with the signaling parameter. for example, the AAL type (AAL 3,4 or AAL 5) for the sigAalTypeType." ::= { atmSigParamEntry 4 } atmSigParamRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The usual stuff." ::= { atmSigParamEntry 5 } The atmVclTable and atmVclExtTable will have to be modified to use the atmSigParamIndex to select a set of parameters associated with the VCL.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18102; 27 Apr 95 22:54 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa18098; 27 Apr 95 22:54 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa20268; 27 Apr 95 22:54 EDT Received: from atmsys.com (isthmus.atmsys.com [198.211.211.2]) by thumper.bellcore.com (8.6.9/8.6.10) with SMTP id WAA00869 for ; Thu, 27 Apr 1995 22:33:49 -0400 Received: from beauty.atmsys.com ([144.10.1.2]) by atmsys.com (4.1/SMI-4.1/ATMsys) id AA00721; Thu, 27 Apr 95 19:33:06 PDT Received: from atmsys.com by atmsys.com (4.1/SMI-4.1/ATMsys) id AA04209; Thu, 27 Apr 95 19:33:06 PDT Received: by shumba.atmsys.com (5.x/SMI-SVR4) id AA16411; Thu, 27 Apr 1995 19:33:01 -0700 Date: Thu, 27 Apr 1995 19:33:01 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Ross Schibler Message-Id: <9504280233.AA16411@shumba.atmsys.com> To: asmith@baynetworks.com Subject: <21> Separation of PVC/SVC tables Cc: atommib@thumper.bellcore.com X-Sun-Charset: US-ASCII > From asmith@Baynetworks.COM Wed Apr 26 14:51 PDT 1995 > > From: kaj@cc.bellcore.com (Kaj Tesink) > > But some questions to ask are: > Some data points with our NMS application hats on (as opposed to > our Agent implementor hats): > > > - what are the applications that use the SVC-only request? > Can't think of any. Call tracing. User wants to know why his SVC is not working correctly ("why am I getting so much jitter on this video?") where it got routed to, etc. The application needs to *examine* the interfaces/parameters asociated with a call. On the other hand a PVC manager application is *configuring* circuits. This managing entity would want RW access (as per rfc-1695) to the connections, while the entity looking at SVC calls should be only given RO access. If we don't have two tables (with different access controls), a PVC manager application could destroy/re-route an existing SVC. I dont think this is a good thing. Clearly, the existing RFC-1695 is written from the perspective of an NMS doing create/destroys on rows (i.e. creating PVCs/PVPs). This mechanism does not make sence for examining SVCs (or SVPs). We already have different tables for PVCs and another for PVPs. I think we want different tables for the different functions, and should add a new table for SVCs. > > - how frequent is this table retrieval typically needed? > Very infrequent for the whole table. Needs to be efficient for individual > PVC/SVC (don't care about which type) lookups. Agreed. More importantly - needs to be *very* efficient for the call control/signalling entity to add information as SVCs are created. > > - how big is the table typically? > PVCs: small, SVCs: 1000s I'd say SVCs: 10,000s (might be nearer 100,000 for very large switches) > > - what is the typical ratio between SVCs and PVCs? > Usually 100%:0% or 0%:100%. Only occasionally is there likely to be a mixture. Seems to make a case for separate tables. > Andrew & Faye Ross _______________________________________________________________________ Ross Schibler ATM Systems (a division of Connectware, an AMP company) 989 E. Hillsdale Blvd email: ross@atmsys.com Foster City, voice: (415)358-1390 California 94404 fax: (415)358-0592   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01625; 28 Apr 95 7:25 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01621; 28 Apr 95 7:25 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa03441; 28 Apr 95 7:25 EDT Received: from theseas.ntua.gr (theseas.ntua.gr [147.102.1.1]) by thumper.bellcore.com (8.6.9/8.6.10) with ESMTP id GAA23459 for ; Fri, 28 Apr 1995 06:52:49 -0400 Received: by theseas.ntua.gr with ESMTP; Fri, 28 Apr 1995 13:55:24 +0300 Received: by phgasos.ntua.gr (8.6.10/NTUA-2.98-SunOS) id NAA19564; Fri, 28 Apr 1995 13:26:06 +0300 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Tryphon Chiotis Message-Id: <199504281026.NAA19564@phgasos.ntua.gr> Subject: Wireless ATM MIB To: atommib@thumper.bellcore.com Date: Fri, 28 Apr 1995 13:26:06 +0300 (EET DST) X-Mailer: ELM [version 2.4 PL21] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1007 Dear colleagues Does anybody know any work towards the management of wireless ATM networks (e.g. MIB specification). Regards, Tryphon -- _____________________________________________________________________ | | | Tryphon Chiotis | | | | Network Management & Optimal Design Laboratory (NETMODE) | | Computer Science Division | | Electrical & Computer Engineering Department | | National Technical University of Athens (NTUA) | | 15780, Zografou, Athens, Greece | | E-mail: tchiotis@phgasos.ntua.gr | | Tel:+301.7484.922, Fax: +301.7790.186 | |_____________________________________________________________________|   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02122; 28 Apr 95 8:31 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02118; 28 Apr 95 8:31 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa04439; 28 Apr 95 8:31 EDT Received: from theseas.ntua.gr (theseas.ntua.gr [147.102.1.1]) by thumper.bellcore.com (8.6.9/8.6.10) with ESMTP id HAA26233 for ; Fri, 28 Apr 1995 07:55:03 -0400 Received: by theseas.ntua.gr with ESMTP; Fri, 28 Apr 1995 14:57:50 +0300 Received: by phgasos.ntua.gr (8.6.10/NTUA-2.98-SunOS) id OAA27696; Fri, 28 Apr 1995 14:58:34 +0300 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Tryphon Chiotis Message-Id: <199504281158.OAA27696@phgasos.ntua.gr> Subject: Wireless ATM MIB To: atommib@thumper.bellcore.com Date: Fri, 28 Apr 1995 14:58:33 +0300 (EET DST) X-Mailer: ELM [version 2.4 PL21] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1007 Dear colleagues Does anybody know any work towards the management of wireless ATM networks (e.g. MIB specification). Regards, Tryphon -- _____________________________________________________________________ | | | Tryphon Chiotis | | | | Network Management & Optimal Design Laboratory (NETMODE) | | Computer Science Division | | Electrical & Computer Engineering Department | | National Technical University of Athens (NTUA) | | 15780, Zografou, Athens, Greece | | E-mail: tchiotis@phgasos.ntua.gr | | Tel:+301.7484.922, Fax: +301.7790.186 | |_____________________________________________________________________|   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02746; 28 Apr 95 9:50 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02742; 28 Apr 95 9:50 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa06187; 28 Apr 95 9:50 EDT Received: from mail.bellcore.com (mail.bellcore.com [128.96.90.10]) by thumper.bellcore.com (8.6.9/8.6.10) with SMTP id JAA01734 for ; Fri, 28 Apr 1995 09:18:19 -0400 Received: from eve (eve.bellcore.com) by mail.bellcore.com (5.65c/2.1) id AA26981; Fri, 28 Apr 1995 09:09:27 -0400 Received: from [128.96.82.154] (nv-ktesink.cc.bellcore.com) by eve (4.1/4.7) id AA07802; Fri, 28 Apr 95 09:22:41 EDT Date: Fri, 28 Apr 95 09:22:40 EDT X-Station-Sent-From: eve.bellcore.com X-Sender: kaj@eve.bellcore.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: atommib@thumper.bellcore.com Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Kaj Tesink Subject: Re: <21> Separation of PVC/SVC tables At 2:33 AM 4/28/95, Ross Schibler wrote: >> From asmith@Baynetworks.COM Wed Apr 26 14:51 PDT 1995 >> > From: kaj@cc.bellcore.com (Kaj Tesink) > >> > But some questions to ask are: >> Some data points with our NMS application hats on (as opposed to >> our Agent implementor hats): >> >> > - what are the applications that use the SVC-only request? >> Can't think of any. > >Call tracing. User wants to know why his SVC is not working correctly >("why am I getting so much jitter on this video?") where it got routed >to, etc. The application needs to *examine* the interfaces/parameters >asociated with a call. Yes, this is a nice application, but in this case you would already know the particular connection, and there wouldnt be a reason to retrieve all PVC or all SVC info. > >On the other hand a PVC manager application is *configuring* circuits. >This managing entity would want RW access (as per rfc-1695) to the >connections, while the entity looking at SVC calls should be only given >RO access. If we don't have two tables (with different access controls), >a PVC manager application could destroy/re-route an existing SVC. I >dont think this is a good thing. Clearly, the existing RFC-1695 is >written from the perspective of an NMS doing create/destroys on rows >(i.e. creating PVCs/PVPs). This mechanism does not make sence for >examining SVCs (or SVPs). I'd agree with that, but I'd also assume that the application knows what its doing; it will manipulate a connection for a specific purpose. Note also that there is a way to find out whether a particular connection is a PVC or an SVC. > We already have different tables for PVCs and >another for PVPs. I think we want different tables for the different >functions, and should add a new table for SVCs. > >> > - how frequent is this table retrieval typically needed? >> Very infrequent for the whole table. Needs to be efficient for individual >> PVC/SVC (don't care about which type) lookups. > >Agreed. More importantly - needs to be *very* efficient for the call >control/signalling entity to add information as SVCs are created. > >> > - how big is the table typically? >> PVCs: small, SVCs: 1000s > >I'd say SVCs: 10,000s (might be nearer 100,000 for very large switches) > >> > - what is the typical ratio between SVCs and PVCs? >> Usually 100%:0% or 0%:100%. Only occasionally is there likely to be a mixture. > >Seems to make a case for separate tables. > >> Andrew & Faye > >Ross > _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ _/ _/ _/ Kaj Tesink _/ _/ Bellcore _/ _/ - Broadband Data Services & Consulting vmail (908) 758-5254 _/ _/ 331 Newman Springs Rd. email kaj@cc.bellcore.com _/ _/ Red Bank, NJ 07701 faxmail (908) 758-4196 _/ _/ _/ _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07347; 28 Apr 95 19:38 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07343; 28 Apr 95 19:38 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa16384; 28 Apr 95 19:38 EDT Received: from atmsys.com (isthmus.atmsys.com [198.211.211.2]) by thumper.bellcore.com (8.6.9/8.6.10) with SMTP id TAA19106 for ; Fri, 28 Apr 1995 19:17:20 -0400 Received: from beauty.atmsys.com ([144.10.1.2]) by atmsys.com (4.1/SMI-4.1/ATMsys) id AA00760; Fri, 28 Apr 95 16:16:31 PDT Received: from atmsys.com by atmsys.com (4.1/SMI-4.1/ATMsys) id AA11475; Fri, 28 Apr 95 16:16:25 PDT Received: by mojave.atmsys.com (5.x/SMI-SVR4) id AA04989; Fri, 28 Apr 1995 16:16:22 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Felix Jan Message-Id: <9504282316.AA04989@mojave.atmsys.com> Subject: Re: Signaling Parameters in ATM MIBs To: Faye Ly Date: Fri, 28 Apr 1995 16:16:21 -0700 (PDT) Cc: atommib@thumper.bellcore.com In-Reply-To: <9504272035.AA26000@mystical> from "Faye Ly" at Apr 27, 95 01:35:15 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Faye, >In the ATM MIB WG in Danvers, James (NewBridge) proposed another way of >dealing with the signaling parameters as opposed to the current proposal >which is done in two tables: atmSigDescrParamTable in supplemental MIB >and atmTrafficDescrParamTable in RFC 1695. > >I thought that was a good idea since it first consolidates these >two tables and second provides flexibility for future expansion >such as UNI 4.0. It basically puts all signaling parameters in >an OID tree. New signaling parameters can be registered as soon >as they are defined. The data of the signaling parameters are >stored in a separate table which has the tuple of { a straight >numerical index, OID of the signaling parameter, value or data >associated with the signaling parameter }. >The signaling of a VC is specified by selecting the entries from >this table which is similar to how it works now. > I can see the flexibility of this approach since new parameters can be added easily without defining another extension table. But, this approach lacks efficiency since there will be too many table lookups to find an appropriate set of parameters to use. And, it also miss TYPE information for those parameters currently defined since the atmSigParamValue field has been defined as "OCTET STRING" in this approach. If there are total of N sets of parameters created in the table and M parameters per set. To select an appropriate set of parameters, one has to look up the table N * M times (worst case). Let say, N=10 and M=20 N*M = 10 * 20 = 200. What I propose is to extend the current approach defined in RFC1695 extension. We can do a best guess how many additional parameters (take the maximum) might be defined in the future and add those additional parameters in the sigParmDescrTable. And, also define a field , atmSigDescrParamColInuse, to specify how many parameters are currently defined. Let say we guess five more parameters might be added in signaling descriptor parameter table in the future. The AtmSigDescrParamEntry will look like this: AtmSigDescrParamEntry ::= SEQUENCE { atmSigDescrParamIndex AtmSigDescrParamIndex, atmSigDescrParamColInUse, INTEGER, atmSigDescrParamAalType INTEGER, atmSigDescrParamAalMode INTEGER, atmSigDescrParamAalSscsType INTEGER, atmSigDescrParamBhliType INTEGER, atmSigDescrParamBhliInfo OCTET STRING, atmSigDescrParamBbcClass INTEGER, atmSigDescrParamBbcTraffic INTEGER, atmSigDescrParamBbcTiming INTEGER, atmSigDescrParamBbcClipping INTEGER, atmSigDescrParamBbcConnConf INTEGER, atmSigDescrParamBlliLayer2 INTEGER, atmSigDescrParamBlliLayer3 INTEGER, atmSigDescrParamBlliPktSize INTEGER, atmSigDescrParamBlliSnapId INTEGER, atmSigDescrParamBlliOuiPid OCTET STRING, atmSigDescrParamRsvd1, OCTET STRING, atmSigDescrParamRsvd2, OCTET STRING, atmSigDescrParamRsvd3, OCTET STRING, atmSigDescrParamRsvd4, OCTET STRING, atmSigDescrParamRsvd5, OCTET STRING, atmSigDescrParamRowStatus RowStatus } We can do the same thing for the atmTrafficDescrParamTable. In this case, the atmVclTable and atmVclExtTable need not be modified to select a set of parameters associated with the VCL. Regards, Felix Jan. (felixj@atmsys.com)   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07726; 28 Apr 95 20:30 EDT Received: from [132.151.1.1] by IETF.CNRI.Reston.VA.US id aa07722; 28 Apr 95 20:30 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa17057; 28 Apr 95 20:30 EDT Received: from atmsys.com (isthmus.atmsys.com [198.211.211.2]) by thumper.bellcore.com (8.6.9/8.6.10) with SMTP id UAA21459 for ; Fri, 28 Apr 1995 20:08:16 -0400 Received: from beauty.atmsys.com ([144.10.1.2]) by atmsys.com (4.1/SMI-4.1/ATMsys) id AA01393; Fri, 28 Apr 95 17:07:35 PDT Received: from atmsys.com by atmsys.com (4.1/SMI-4.1/ATMsys) id AA11697; Fri, 28 Apr 95 17:07:34 PDT Received: by mojave.atmsys.com (5.x/SMI-SVR4) id AA05123; Fri, 28 Apr 1995 17:07:31 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Felix Jan Message-Id: <9504290007.AA05123@mojave.atmsys.com> Subject: Re: Signaling Parameters in ATM MIBs To: atommib@thumper.bellcore.com Date: Fri, 28 Apr 1995 17:07:30 -0700 (PDT) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Faye, >In the ATM MIB WG in Danvers, James (NewBridge) proposed another way of >dealing with the signaling parameters as opposed to the current proposal >which is done in two tables: atmSigDescrParamTable in supplemental MIB >and atmTrafficDescrParamTable in RFC 1695. > >I thought that was a good idea since it first consolidates these >two tables and second provides flexibility for future expansion >such as UNI 4.0. It basically puts all signaling parameters in >an OID tree. New signaling parameters can be registered as soon >as they are defined. The data of the signaling parameters are >stored in a separate table which has the tuple of { a straight >numerical index, OID of the signaling parameter, value or data >associated with the signaling parameter }. >The signaling of a VC is specified by selecting the entries from >this table which is similar to how it works now. > I can see the flexibility of this approach since new parameters can be added easily without defining another extension table. But, this approach lacks efficiency since there will be too many table lookups to find an appropriate set of parameters to use. And, it also miss TYPE information for those parameters currently defined since the atmSigParamValue field has been defined as "OCTET STRING" in this approach. If there are total of N sets of parameters created in the table and M parameters per set. To select an appropriate set of parameters, one has to look up the table N * M times (worst case). Let say, N=10 and M=20 N*M = 10 * 20 = 200. What I propose is to extend the current approach defined in RFC1695 extension. We can do a best guess how many additional parameters (take the maximum) might be defined in the future and add those additional parameters in the sigParmDescrTable. And, also define a field , atmSigDescrParamColInuse, to specify how many parameters are currently defined. Let say we guess five more parameters might be added in signaling descriptor parameter table in the future. The AtmSigDescrParamEntry will look like this: AtmSigDescrParamEntry ::= SEQUENCE { atmSigDescrParamIndex AtmSigDescrParamIndex, atmSigDescrParamColInUse, INTEGER, atmSigDescrParamAalType INTEGER, atmSigDescrParamAalMode INTEGER, atmSigDescrParamAalSscsType INTEGER, atmSigDescrParamBhliType INTEGER, atmSigDescrParamBhliInfo OCTET STRING, atmSigDescrParamBbcClass INTEGER, atmSigDescrParamBbcTraffic INTEGER, atmSigDescrParamBbcTiming INTEGER, atmSigDescrParamBbcClipping INTEGER, atmSigDescrParamBbcConnConf INTEGER, atmSigDescrParamBlliLayer2 INTEGER, atmSigDescrParamBlliLayer3 INTEGER, atmSigDescrParamBlliPktSize INTEGER, atmSigDescrParamBlliSnapId INTEGER, atmSigDescrParamBlliOuiPid OCTET STRING, atmSigDescrParamRsvd1, OCTET STRING, atmSigDescrParamRsvd2, OCTET STRING, atmSigDescrParamRsvd3, OCTET STRING, atmSigDescrParamRsvd4, OCTET STRING, atmSigDescrParamRsvd5, OCTET STRING, atmSigDescrParamRowStatus RowStatus } We can do the same thing for the atmTrafficDescrParamTable. In this case, the atmVclTable and atmVclExtTable need not be modified to select a set of parameters associated with the VCL. Regards, Felix Jan. (felixj@atmsys.com)   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01741; 29 Apr 95 11:12 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01737; 29 Apr 95 11:12 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa05840; 29 Apr 95 11:12 EDT Received: from icarus.lis.pitt.edu (icarus.lis.pitt.edu [136.142.116.2]) by thumper.bellcore.com (8.6.9/8.6.10) with SMTP id KAA25475 for ; Sat, 29 Apr 1995 10:47:21 -0400 Received: from thrasher.lis.pitt.edu by icarus.lis.pitt.edu (4.1/1.34) id AA21797; Sat, 29 Apr 95 10:47:38 EDT Date: Sat, 29 Apr 95 10:47:38 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Muh-rong Yang Message-Id: <9504291447.AA21797@icarus.lis.pitt.edu> To: atommib@thumper.bellcore.com Subject: unscribe   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08383; 29 Apr 95 23:11 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08379; 29 Apr 95 23:11 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa14305; 29 Apr 95 23:11 EDT Received: from foxhound.cisco.com (foxhound.cisco.com [171.69.1.171]) by thumper.bellcore.com (8.6.9/8.6.10) with ESMTP id WAA17843 for ; Sat, 29 Apr 1995 22:47:09 -0400 Received: (kzm@localhost) by foxhound.cisco.com (8.6.8+c/8.6.5) id TAA11346; Sat, 29 Apr 1995 19:47:04 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Keith McCloghrie Message-Id: <199504300247.TAA11346@foxhound.cisco.com> Subject: Re: Signaling Parameters in ATM MIBs To: Felix Jan Date: Sat, 29 Apr 95 19:47:04 PDT Cc: faye@baynetworks.com, atommib@thumper.bellcore.com In-Reply-To: <9504282316.AA04989@mojave.atmsys.com>; from "Felix Jan" at Apr 28, 95 4:16 pm X-Mailer: ELM [version 2.3 PL11] First, I would observe that these parameters (or at least a subset of them) are for use by PVCs and SVCs, so to my mind, atmSigDescrXxx is the wrong name. > >In the ATM MIB WG in Danvers, James (NewBridge) proposed another way of > >dealing with the signaling parameters as opposed to the current proposal > >which is done in two tables: atmSigDescrParamTable in supplemental MIB > >and atmTrafficDescrParamTable in RFC 1695. > > > >.... > > I can see the flexibility of this approach since new parameters can be added > easily without defining another extension table. But, this approach lacks > efficiency since there will be too many table lookups to find an appropriate > set of parameters to use. And, it also miss TYPE information for those > parameters currently defined since the atmSigParamValue field has been defined > as "OCTET STRING" in this approach. > > If there are total of N sets of parameters created in the table > and M parameters per set. To select an appropriate set of parameters, one > has to look up the table N * M times (worst case). Let say, N=10 and M=20 > N*M = 10 * 20 = 200. I agree. It adds considerable complexity. To setup one set of these parameters takes a row-creation for each parameter. In addition, expereince from other MIBs indicates that extra procedure is necessary to avoid multiple NMSs from colliding when creating rows when a row is doubly indexed (cf. viewNextIndex in snmpV2). > What I propose is to extend the current approach defined in RFC1695 extension. > We can do a best guess how many additional parameters (take the maximum) > might be defined in the future and add those additional parameters in the > sigParmDescrTable. And, also define a field , atmSigDescrParamColInuse, > to specify how many parameters are currently defined. > > Let say we guess five more parameters might be added in signaling descriptor > parameter table in the future. The AtmSigDescrParamEntry will look like this: I don't like your suggestion either. What happens if there were to be six more (and my understanding of the current status of ABR is that there might well be lots more coming in the future!!). I would prefer that we go back to what Faye had in her original proposal, and that we extend that (as and when necessary) by defining new tables using AUGMENTS. Keith.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01948; 30 Apr 95 13:27 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01944; 30 Apr 95 13:27 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa07366; 30 Apr 95 13:27 EDT Received: from nbkanata.newbridge.com (Newbridge.COM [192.75.23.5]) by thumper.bellcore.com (8.6.9/8.6.10) with SMTP id NAA14824 for ; Sun, 30 Apr 1995 13:02:46 -0400 Received: from thor.Newbridge.com by nbkanata.newbridge.com (4.1/SMI-4.1) id AA26803; Sun, 30 Apr 95 13:02:25 EDT Received: from fields.newbridge by thor.Newbridge.com (4.1/SMI-4.0) id AA17660; Sun, 30 Apr 95 13:02:42 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: James Watt Message-Id: <9504301702.AA17660@thor.Newbridge.com> Subject: Re: Signaling Parameters in ATM MIBs To: AToMib Date: Sun, 30 Apr 1995 13:02:41 -0400 (EDT) In-Reply-To: <199504300247.TAA11346@foxhound.cisco.com> from "Keith McCloghrie" at Apr 29, 95 07:47:04 pm X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1200 I have to admit I even made disparaging comments about the implementation complexity. The reason I didn't discard the idea out of hand however, was that I was only thinking about SVCs. Someone observed that it would not be the NMS that created the row, rather applications will specify the parameters and the signalling layer will be keeping track of them. I was trying to make the agent's job easy on the grounds it wouldn't cost the NMS much becuase the NMS wouldn't ever need to set them up. However, if you want to be able to set these up for PVCs, then it doesn't fly. Also, it recently occurred to me that whilst the application might tell signaling what it wants, the NMS might tell the application to use "entry 123 in the signaling table" to tell signaling what to do. Thus even in the SVC case, easy NMS setup would seem to be imperative. Which brings me to my real question: how would this (say with the original proposal) be used ? Regards, -james ____________________________________________________________________________ James W. Watt, james@newbridge.com Ph: +1 613 591-3600 Newbridge Networks 600 March Rd Kanata ON Canada K2K 2E6 FAX:+1 613 591-3680   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02309; 30 Apr 95 15:24 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02305; 30 Apr 95 15:24 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa08764; 30 Apr 95 15:24 EDT Received: from foxhound.cisco.com (foxhound.cisco.com [171.69.1.171]) by thumper.bellcore.com (8.6.9/8.6.10) with ESMTP id PAA18547 for ; Sun, 30 Apr 1995 15:02:08 -0400 Received: (kzm@localhost) by foxhound.cisco.com (8.6.8+c/8.6.5) id MAA25955; Sun, 30 Apr 1995 12:02:03 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Keith McCloghrie Message-Id: <199504301902.MAA25955@foxhound.cisco.com> Subject: Re: <21> Separation of PVC/SVC tables To: Ross Schibler Date: Sun, 30 Apr 95 12:02:03 PDT Cc: asmith@baynetworks.com, atommib@thumper.bellcore.com In-Reply-To: <9504280233.AA16411@shumba.atmsys.com>; from "Ross Schibler" at Apr 27, 95 7:33 pm X-Mailer: ELM [version 2.3 PL11] > > > - what are the applications that use the SVC-only request? > > Can't think of any. > > Call tracing. User wants to know why his SVC is not working correctly > ("why am I getting so much jitter on this video?") where it got routed > to, etc. The application needs to *examine* the interfaces/parameters > asociated with a call. Yes, and call-tracing is needed for both PVCs and SVCs, and it's easier for the NMS to have PVCs/SVCs combined into one table, especially because of soft-PVCs which are PVCs on some links and SVCs on other links. > On the other hand a PVC manager application is *configuring* circuits. > This managing entity would want RW access (as per rfc-1695) to the > connections, while the entity looking at SVC calls should be only given > RO access. If we don't have two tables (with different access controls), > a PVC manager application could destroy/re-route an existing SVC. I > dont think this is a good thing. I don't see this as a problem; an agent can easily refuse to modify the RowStatus of an SVC. > > > - how frequent is this table retrieval typically needed? > > Very infrequent for the whole table. Needs to be efficient for individual > > PVC/SVC (don't care about which type) lookups. > > Agreed. More importantly - needs to be *very* efficient for the call > control/signalling entity to add information as SVCs are created. Yes, we need efficient lookup by port/VCI/VPI independent of PVC/SVC type. > > > - what is the typical ratio between SVCs and PVCs? > > Usually 100%:0% or 0%:100%. Only occasionally is there likely to be a > > mixture. > > Seems to make a case for separate tables. I disagree with both. I think the normal situation is that there will be a mixture (every system will implement SVCs as some time, and it will be very rare that there are no SVCs active; and I would expect many networks to have some PVCs setup for use in the event that signalling/PNNI fails). However, it is the likelihood of a mixture for which separate tables helps. Another factor which I haven't seen mentioned is that having PVCs/SVCs in the same table makes it easier for an NMS, when setting-up a PVC, to recognize that the VCI/VPI it has chosen clashes with a VCI/VPI of an SVC. The only reason I can see for wanting separate tables is to give the NMS the ability to retrieve all the PVCs without having to do a getNext/getBulk sweep through all PVCs/SVCs. So, for the NMS, I think it's a trade-off between simpler call-tracing and simpler PVC-setup versus having to sweep through the PVCs and SVCs in order to retrieve all the PVCs. For the agent, having fewer tables is simpler. The factor which tips the balance in my mind is soft-PVCs which are part-PVC and part-SVC; because of them, I believe we need to have PVCs/SVCs in the same (CrossConnect) table. If people feel that retrieving all the PVCs needs to be an efficient operation, then we could consider having two additional (read-only) tables for PVCs (one for Vcls and one for Vpls). Keith.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13253; 1 May 95 3:28 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa13249; 1 May 95 3:28 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa17984; 1 May 95 3:28 EDT Received: from VNET.IBM.COM (vnet.ibm.com [199.171.26.4]) by thumper.bellcore.com (8.6.9/8.6.10) with SMTP id CAA11783 for ; Mon, 1 May 1995 02:55:47 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: jbs@vnet.ibm.com Message-Id: <199505010655.CAA11783@thumper.bellcore.com> Received: from LGEPROFS by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 5953; Mon, 01 May 95 02:55:33 EDT Date: Mon, 1 May 95 08:55:51 FST To: kaj@cc.bellcore.com Cc: atommib@thumper.bellcore.com Subject: <21> Separation of PVC/SVC tables Kaj, in my humble opinion, I believe the base problem we're having with these tables is a modelling issue. At the begining of the AToMMIB, we clearly stated the difference between virtual links (VPL/VCL) that have a local meaning and virtual connection (could be SVC/PVC/smart PVCs) that have an end-to-end meaning. In fact, in the cross-connect table as currently defined, we are: - mixing all PVCs (smart or not) and SVCs in the same table - trying to mix local information (element-level view) and end-to-end (network-level view) information I totally agree with some of the comments already made on the drawbacks that this creates, in-line with my personal comments/experience: - agents (switches) have to allocate and maintain connection-ids for SVC and process get-next requests accordingly. This breaks the optimisatio of processing in terms of compromise cost/performance/memory (I agree that this might not be a problem for SPE, but that's one for CPE) Typically, for instance, you would organize local SVCs information on hashing mechanism and don't want to handle on top of that a connection id just for SNMP get-requests that we don't know the use of it. - there was an argument for call tracing: in fact, the way this table is organised doubles the cost of connection tracing: if I want to trace the connection, let's say if=x,VPI=y,VCI=z, I have to do first a get into the VCL table to find the corresponding connection id and then I have to go to the cross-connect table to find the other part of the connection. I have to do this for all switches in the network. - This table does not allow to create smart PVCs (PVCs established using signalling in the network). To do so, there is a need to identify the remote part. The solution that we found the most efficient (both in terms of agents and applications) is the following: - have a local cross-connect table, in the form: table = sequence of X X = sequence : input interface input VPI input VCI output interface output VPI output VCI This table contains entries for *all* cross-connections (whether they are part of a PVC or SVC). It is read-only. There is no identifier. It is used directly, for connection tracing for instance (doing a get-next on input interface, input VPI, input VCI) - have separate tables for Connections. You may have for instance tables for PVCs: One global PVC table: - this table is indexed by a connection-id (same reason as for the current cross-connect table in AToMMIB, the difference is that this is at the network-level; for a smart PVCs, there would be entries at each end of the PVC, not in the intermediate switches) It contains the destination identifier (for smart PVCs). If this field is left blank, this is assumed to be "local" PVC, the same way we use to set them in the current AToMMIB. - an auxilliary table for parties; in case of a pt-to-pt PVC, there is only one entry in this table; in the case of a pt-ot-mpt PVC, there are several entries If we find a use for SVC tables, we could have SVC tables. To summarize, let's assume we have the following: end-system A ----- switch X ----- switch Y ----- switch z ----- es B with: a smart PVC from A to B an SVC from A to B switch X has: one entry for the PVC in the cross-connect table one entry for the SVC in the cross-connect table one entry for the PVC in the PVC table switch Y has: one entry for the PVC in the cross-connect table one entry for the SVC in the cross-connect table switch Z has: one entry for the PVC in the cross-connect table one entry for the SVC in the cross-connect table one entry for the PVC in the PVC table (note: in fact one entry should read "two entries") jbs.