Re: Initiating X.25 calls

[Mark Therieau <[e-mail]>]

>>How then, are multiprotocol virtual circuits managed?  Which client protocol 
>>would provide the destination X.121 address for the call?

>A first guess would be that every client would specify calling parameters
>(X.121 address, negotiable facilities, etc) and the service provider
>would look for an open VC which has matching or acceptable parameters.
>It would open a new SVC if needed.

This approach troubles me because N clients * M VCs == many
configuration headaches.  Currently Microcom's product can deal with 60
simultaneous VCs.  If I want to add IPX routing to my bridging configuration
then I would have to duplicate all 60 X.121 addresses from my bridging
configuration to my IPX routing configuration!  Aaargh!

>>Microcom currently has a product that transmits multiple protocols over a
>>single VC.  The VC is opened on behalf of all client protocols--not just
>>for a single VC.

>Are VCs opened statically or on demand?

Both modes are supported.  Most of our customers, however, configure their
VCs statically.  The configuration specifies the connectivity.  Protocols
are routed or bridged over applicable configured VCs.  In this way, the VCs
are treated in the same manner as leased line point-to-point connections.

>Are multiple VCs to a single destination managed?

No.

>>In my view, multiprotocol traffic seems to dictate a central point of call
>>configurations--not disbursed throughout individual client protocol MIBs.

>I'd argue that the service provider should know as little as possible
>about its client protocols.  A client should specify what services it
>needs/wants.

I agree that services are configurable.  I agree that client protocols
should be able to request specific services.  Maybe terminology is limiting
us here.  What if I defined a client MIB and called it multiProtocolOverX25?
(or SNAPoverX25?)  If we could agree that this is a good and valid client,
then we could avoid developing N fooOverX25 MIBs, each with its own call
configuration table?

>It should be possible for a client to request a VC to be
>opened for its private use.

If site A has opened a multiprotocol VC to site B, but now wants to open
a second VC for private use by say, IPX, how does site B know that the
second VC is for private-use by IPX?  Wouldn't site B assume that the new
VC is for general, multiprotocol use?


markt