Re: Use of atmV.lCrossConnectIdentifier for PVCs/SVCs

Peter Jones <> Thu, 26 March 1998 04:37 UTC

Delivery-Date: Wed, 25 Mar 1998 23:37:21 -0500
Received: from (cnri []) by (8.8.7/8.8.7a) with ESMTP id XAA20786 for <>; Wed, 25 Mar 1998 23:37:20 -0500 (EST)
Received: from ( []) by (8.8.5/8.8.7a) with ESMTP id XAA14190 for <>; Wed, 25 Mar 1998 23:39:51 -0500 (EST)
Received: from ( []) by (8.8.8/8.8.8) with SMTP id VAA07722 for <>; Wed, 25 Mar 1998 21:51:31 -0500 (EST)
Received: from by (SMI-8.6/SMI-SVR4) id KAA02423; Thu, 26 Mar 1998 10:50:49 +0800
Message-ID: <>
Date: Thu, 26 Mar 1998 10:50:46 +0800
From: Peter Jones <>
Organization: Atmosphere Networks
X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: Gary Hanson <>
CC: Mickey Spiegel <>, Kaj Tesink <>,, John Neil <>
Subject: Re: Use of atmV.lCrossConnectIdentifier for PVCs/SVCs
References: <Pine.SUN.3.96.980320145743.18024N-100000@skeeter>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Gary,

Gary Hanson wrote:
> Mickey, Kaj, (and other atommib-ers),
> I have been trying to dig through the atommib WG archives to find
> the final consensus on how the atmVplCrossConnectIdentifier and
> the atmVclCrossConnectIdentifier objects should be used to refer to
> the various PVC- and SVC-related cross-connect tables.  Since the
> current internet-drafts are essentially silent on this point, I
> thought I would throw the question open to other implementors on
> the mailing list to see what they had done (or intended to do).
> To refresh people memories, the following table entries are all
> defined to be partially indexed by a cross-connect index in the
> range 0..2147483647):
> - From ATM-MIB:
>   - atmVpCrossConnectEntry    (1st INDEX: atmVpCrossConnectIndex)
>   - atmVcCrossConnectEntry    (1st INDEX: atmVcCrossConnectIndex)
> - From ATM2-MIB:
>   - atmSvcVpCrossConnectEntry (1st INDEX: atmSvcVpCrossConnectIndex)
>   - atmSvcVcCrossConnectEntry (1st INDEX: atmSvcVcCrossConnectIndex)
> The cross-connect index values used as INDEXes into these tables
> are all apparently derived from the following objects from ATM-MIB:
>   - atmVplCrossConnectIdentifier (from atmVplEntry)
>   - atmVclCrossConnectIdentifier (from atmVclEntry)
> As far as I can tell, neither the ATM-MIB draft nor the ATM2-MIB
> draft clarify how the atmV.lCrossConnectIdentifier objects from
> the atmV.lEntry rows are to be used to identify the ATM2-MIB's
> atmSvcV.CrossConnectEntry rows.  In fact, the ATM-MIB draft simply
> says that these objects only identify the atmV.CrossConnectEntry
> rows in the ATM-MIB.
> Was it the intention of the WG that a particular cross-connect
> identifier value be used to identify a row in one table or the
> other, but NEVER both?  For example, if an atmVpCrossConnectEntry
> exists with atmVpCrossConnectIndex X, should the agent take pains
> to ensure that no atmSvcVpCrossConnectEntry also exists with
> atmSvcVpCrossConnectIndex X, and vice versa?  This would make
> sense to me, but as the documents do not explicitly say this, I
> was left somewhat unsure.
> I assume that the WG has abandoned the idea of splitting the
> cross-connect identifier values into two disjoint ranges, since
> there had been a lot of negative discussion about that, and since
> the tables do in fact now share the same indexing range.  So am I
> correct in assuming that the tables share the same range of index
> values, but NEVER share entries indexed by the same cross-connect
> index value?
> If so, what does the WG think about adding explicit documentation
> to this effect in both documents.  The ATM-MIB document deserves
> to have this mentioned, since that is where the cross-connect
> identifier is defined, and the ATM2-MIB document also deserves to
> have this mentioned, since there is otherwise no explicit mention
> of where the values for atmSvcV.CrossConnectIndex come from.  I
> am sure other implementors will come along with the same confusion
> as myself.
> Regards,
> Gary

>From our point of view, both the SVC's and the PVC's share a 
common pool for cross connect indexes.

This is particularly critical which you consider the case of a soft PVC
at the edge switch. In this case (according to our interpretation)  
one link of the connecton is a PVC link which is then cross connected 
to an SVC link.

I guess this does beg the question as to why we need two lots of cross 
connect tables?


Peter Jones                           Atmosphere Networks
Manager of Software Development       4th Floor, Balcroft Building
                                      Garden Office Park
                                      345 Harborne Street
                                      Osborne Park WA 6017, Australia
Direct: +61 (8) 9443 0105             Main: +61 (8) 9443 0100
                                      Fax:  +61 (8) 9443 6610