Re: Initiating X.25 calls

[Art Berggreen <[e-mail]>]

>
>Please note that the iplpdn working group is proposing a multiprotocol 
>encapsulation for X.25.  Basically this proposal calls for IP traffic to
>go on one VC between two sites, while all other traffic uses a VC with a
>multiprotocol encapsulation.

Yes, I've been tracking that.  It may be needed for practical mapping
of Frame Relay services into X.25 services.

>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.

A more subtle issue would be circuit congestion and closing management.
What do you do if multiple clients produce more data than a single
VC can handle.  When do you open a new VC? If multiple VCs are open,
what about protocols that require enforcement of packet sequence
(which multiple VCs generally breaks)?  Distinguishing between the
case of insufficient window (where multiple VCs will help) and the
case of a link bandwidth bottleneck (where multiple VCs don't help)
is not simple.  Also, with multiple clients, do you try to dynamically
close idle VCs?  The traffic statistics with multiple protocol clients
may be fairly complex.

>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?  Are multiple VCs to a single
destination managed?

>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.  It should be possible for a client to request a VC to be
opened for its private use.

These all seem like good issues though, any other viewpoints?

Art