Subject: Use of atmV.lCrossConnectIdentifier for PVCs/SVCs

From: Gary Hanson <[email-masked]>
Date: Fri, 20 Mar 1998 15:25:15 -0800 (PST)

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: Peter Jones <[email-masked]>
Date: Thu, 26 Mar 1998 10:50:46 +0800

Hi 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?

regards
peter

-- 
______________________________________________________________________
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
mailto:[email-masked]        http://www.atmospherenet.com
_______________________________________________________________________