Conference azur::mcc

2744.0. "V1.2 DNA5 Bridge, maybe FDDI datatypes broken" by MARVIN::WARWICK (Trevor Warwick) Fri Apr 10 1992 14:54

There is a major problem with the MCC support for some of the DNA5 BRIDGE
subentities, which are implemented for the first time on the DECnis 500/600.

The instance datatypes for the entities "BRIDGE FILTER TYPE" and
"BRIDGE FILTER PID" are defined in the Netman architecture as
"EthernetProtocolType" and "IEEE802SNAPPID" respectively.

They are represented to the user as dash-separated strings of octets, in the
same way as the ID datatype, but "EthernetProtocolType" has two octets, and
"IEEE802SNAPPID" has five. 

DECnet-Ultrix already supports these datatypes correctly. I was informed in my
original discussions with the MCC group that MCC supported these datatypes as
of V1.1. They are also used in the Phase V FDDI architecture.

I have just had the chance to try them out, and they don't work. Either the
datatype support is not there, or the MSL is wrong.

"BRIDGE FILTER TYPE" comes across in CMIP as a SimpleName, rather than as
the correct fixed encoding.

"BRIDGE FILTER TYPE" comes across in CMIP as an ID, which is the wrong
datatype (and one octet too long).

Below there are some CMIP and ASN.1 dumps of what MCC provides, and what
Ultrix provides. Since there is no public QAR database, could one of the MCC
developers please QAR this for me.


Trevor Warwick


! CREATE BRIDGE FILTER TYPE 11-22 from MCC T1.2.4

%ASN1-S-DISPASN1, received ASN.1 item:
[ 1 ]
 {
 [UNIVERSAL 2 ] 1 -- Integer
 [UNIVERSAL 2 ] 7 -- Integer
 [UNIVERSAL 16 ]
  {
  [ 0 ] 2B 0C 02 87 73 02 01 01 26 06
  [ 3 ]
   {
   [UNIVERSAL 5 ] -- Null
   [APPLICATION 26 ] 01 05 31 31 2D 32 32
   }
  [ 11 ] 00
  }
 }


%ASN1-S-DISPCMIP, received CMIP message:
Invoke (ID = 1)
 Action
 Entity class = 38 6
 Entity instance = NULL  11-22 (Simplename)
 Action Type = 0


! CREATE BRIDGE FILTER PID 11-22-33-44-55-66 from MCC T1.2.4

%ASN1-S-DISPASN1, received ASN.1 item:
[ 1 ]
 {
 [UNIVERSAL 2 ] 1 -- Integer
 [UNIVERSAL 2 ] 7 -- Integer
 [UNIVERSAL 16 ]
  {
  [ 0 ] 2B 0C 02 87 73 02 01 01 26 05
  [ 3 ]
   {
   [UNIVERSAL 5 ] -- Null
   [APPLICATION 34 ] 11 22 33 44 55 66
   }
  [ 11 ] 00
  }
 }


%ASN1-S-DISPCMIP, received CMIP message:
Invoke (ID = 1)
 Action
 Entity class = 38 5
 Entity instance = NULL  11 22 33 44 55 66  (ID)
 Action Type = 0

! CREATE BRIDGE FILTER TYPE 11-22 from Ultrix

[ 1 ]
 {
 [UNIVERSAL 2 ] 8 -- Integer
 [UNIVERSAL 2 ] 7 -- Integer
 [UNIVERSAL 16 ]
  {
  [ 0 ] 2B 0C 02 87 73 02 01 01 26 06
  [ 3 ]
   {
   [UNIVERSAL 5 ] -- Null
   [APPLICATION 66 ] 11 22
   }
  [ 11 ] 00
  }
 }


%ASN1-S-DISPCMIP, received CMIP message:
Invoke (ID = 8)
 Action
 Entity class = 38 6
 Entity instance = NULL  11 22  (Unknown Tag = 66)
 Action Type = 0


! CREATE BRIDGE FILTER PID 11-22-33-44-55 from Ultrix
%ASN1-S-DISPASN1, received ASN.1 item:
[ 1 ]
 {
 [UNIVERSAL 2 ] 1 -- Integer
 [UNIVERSAL 2 ] 7 -- Integer
 [UNIVERSAL 16 ]
  {
  [ 0 ] 2B 0C 02 87 73 02 01 01 26 05
  [ 3 ]
   {
   [UNIVERSAL 5 ] -- Null
   [APPLICATION 67 ] 11 22 33 44 55
   }
  [ 11 ] 00
  }
 }


%ASN1-S-DISPCMIP, received CMIP message:
Invoke (ID = 1)
 Action
 Entity class = 38 5
 Entity instance = NULL  11 22 33 44 55  (Unknown Tag = 67)
 Action Type = 0

QAR 2723

The answer to QAR 2723 indicates that investigation has started,
but that no fix is likely for the V1.2 kit (which is essentially frozen)

Actually, I  believe  the problems were tracked down to being an MSL problem
which *is* fixed in T1.2.7.

Thanks are particularly due to Arun Sankar who helped sort this out.

Graham

The answer for QAR 02723 now reads:

This turned out to simply be an MSL problem which was fixed in time
for DECmcc V1.2.