[comp.protocols.iso.x400] Protocol analyzer for ISO stacks

wjdh@ciba-geigy.ch (Jean Daniel Horner) (06/04/91)

We are desparately looking for protocol analyzing equipment
able to analyze ISO/CCITT protocol stacks (e.g. x.400 email,
ftam, virtual terminal, x.500 directory services). as
interfaces we need serial and ethernet as well as tokenring.
who knows a good product???

what we found up to now with iso capabilities is:

hp: 4972 analyzer (iso software end 91 begin 92, ethernet only)
tekelec: chamaeleon       (WAN only, x400)
Wandel+Goltermann: DA-30 (iso software end 91 begin 92, LAN+WAN)

thank you for hints
armin schweizer

joerg@bdc.ubc.ca (Joerg Messer) (06/04/91)

Please remove me from this list. Thanks.

                    Joerg Messer  |  Email: joerg@bdc.ubc.ca
           Department of Zoology  |         joerg@nexus.bdc.ubc.ca (NeXT)
  University of British Columbia  |  Phone: 604-228-6527
      Vancouver, Canada, V6T 1W5  |  Fax:   604-228-2416

ggm@brolga.cc.uq.oz.au (George Michaelson) (06/04/91)

wjdh@ciba-geigy.ch (Jean Daniel Horner) writes:


>We are desparately looking for protocol analyzing equipment
>able to analyze ISO/CCITT protocol stacks (e.g. x.400 email,
>ftam, virtual terminal, x.500 directory services). as
>interfaces we need serial and ethernet as well as tokenring.
>who knows a good product???

For low-layer protocol elements I have no information. for transport
and above, You should consider using an OSI programming suite like
RETIX or ISODE. This allows you to do complete PDU tracing of the
input and output dataflow. For pre-defined cases it is fairly easy
(if time consuming) to construct drivers to put you into known states
and watch dataflow, certainly to debug connection phase activity this
approach is valid. (I did this to debug some problems connecting to X.400
services between two implementations: set ISODE to accept the TSEL and X.25
address and debug all the OSI stacktrace up until an application specific
exchange, reveals quite a lot about whats being done. post-connection this
model breaks down, but with an application written to match and using ISODE
you can always use IT as a test driver and monitor the flow all the way)

In the case of ISODE it is also free.

In other words, split the requirement into two parts at the network/transport
layer boundary, and approach each separately. Debugging applications like
X.400 and X.500 and FTAM is not best done in a standalone box like a
network analyzer, you want almost limitless diskspace (for traces and PDU
dis-assembly) and a programming library to construct the test drivers.

There are OSI standards that cover the test suites and testing process for
these applications.  There are also bodies like COS which offer service
testing conformance in applications. If you are buying off-the-shelf software
in these areas, you should consider asking what interoperability and other
testing has already been undertaken. -If the application in question has been
tested against many others, but fails on your platform, it points to other
failures such as the lower network stack, or operating system dependencies.

	-george
--
                         George Michaelson
G.Michaelson@cc.uq.oz.au The Prentice Centre      | There's no  market for
                         University of Queensland | hippos in Philadelphia
Phone: +61 7 365 4079    QLD Australia 4072       |          -Bertold Brecht