[comp.protocols.misc] AUSTPAC/TRANSPAC internetwork problems: have you seen this?

george@ditmela.oz (George michaelson) (02/01/88)

	We have discovered a problem with our local X25 switch 
	being used with AUSTPAC/OTC/{other x25 network} which you
	may be interested in. 

	this problem may be seen by anyone who is on a TRANSPAC-like
	X25 network being called from any other X25 network eg IPSS
	in the UK. it is caused by differences in the use & interpretation
	of X.121 addresses at each DTE, and propagated by X25 gateway and
	network provider behaviour.

	PROBLEM:
		Calls in to local host using subaddress routing are accepted
		but clear at once, possibly with error code 05 a7.
		Remote host may not see call connecting but local host
		does. 

		-further problem: diagnostic a7 is referred to international
		provider and/or remote DTE ie no human readable form available
		locally to decode the problem!

	SEE WITH:
		smartnet 3000 series X25 switch and possibly
		any similar box doing sub-address routing from one X25 DCE
		to several hosts. Any host receiving calls off the address
		with no subaddress will function normally. any routing
		ignoring sub-address may function normally.

	WHAT HAPPENS:
		The call request packet when received by the local X25 provider
		has the LOCAL DTE stripped out, leaving the subaddress part
		only.  This is perceived as a feature on certain nets.

		The switch then routes the CR packet to the correct host using 
		its tables.  The host accepts the call.

		The switch sends back a Connect Accept packet *WITH THE LOCAL
		SUBADDRESS IN IT BUT NOT THE FULL LOCAL DTE* as received from
		the local provider.

		The local provider does NOT re-insert the local DTE but passes
		this packet transparently to the gateway, which also passes
		direct to the remote X25 network.

		The remote network and/or DTE checks the CC packet, finds
		a DTE which (a) does not match the called address (b) does not
		conform to *its* idea of X.121 address format, and clears the
		call 05 (network congestion or other problem) a7 (DTE incorrect
		length)

	WHO IS TO BLAME?

		Well... clearly the switch could do better, but you can argue
		that if the network provider strips addresses on incoming 
		calls they should be replaced in all packets going out during
		the connect phase.  In our case we are using a box with
		little support and little configuration for this area. You
		should look carefully at any product & make sure you have
		full control over all fields of all packets if possible.

	FIX:
		(1)	get a switch which you can tailor enough to specify
			ALL fields in ALL packets and write a valid address
			into your CC packet before sending.

		(2)	discuss this feature with your network provider
			they *may* be able to switch it off, or insert full
			DTE into all connect-phase packets instead of leaving
			the CC alone.

		(3)	use other routing mechanisms as a temporary bridge:
			PID or cudf can be used with DTE minus subaddress
			to select several hosts, if the hosts support this
			option:	(the crucial one of ours claims to but the
			kernel crashes in this mode- the option is thus not
			available)

	I suspect this problem may be being seen by many people but ignored.
	At our site calls to some hosts worked ok, due to the default routing
	on no subaddress creating a CC with no arguments, which was accepted
	by everyone. Local tests fail to cause the problem, even loop-back
	through international gateway may fail to show problem, only a
	genuine call in from some remote net which also checks the DTE on
	all connect phase packets will cause rejection.

	Thanks to OTC and PSS engineers who helped track down this
	problem for us. (at time of writing we don't yet have fix working 
	locally, there may not *be* a fix!)

	George Michaelson.

-- 
ACSnet:	G.Michaelson@ditmela.oz.au
Postal:	55 Barry St, Carlton, Vic 3053
Phone:	(03) 347 8644 				Fax:	(03) 347 8987

rob@COS.COM (Rob Clark) (02/05/88)

In article <284@ditmela.oz>, george@ditmela.oz (George michaelson) writes:
> 
> 	We have discovered a problem with our local X25 switch 
> 	being used with AUSTPAC/OTC/{other x25 network} which you
> 	may be interested in. 
> 

I had a chat with our X.25 guru who has had experience of transpac-type
networks, and we came up with the following:

I would agree that if the network provider (austpac) is going to
strip the called address (except the subaddress if present) from
incoming call packets, then it should do the converse,  thereby
injecting the network address in that same field (appending intact the
subaddress which is returned by the switch which is interposed
between the network provider and the one or more x25 hosts).

I would think, though, that the interposed switch should be capable
of creating a proper full x121 called address in the
extended accept packet. It really should be its responsibility to act
as the network interface to all of its attached DTEs.  (Although it
appears that not even the network provider is doing this detail correctly.)

I know, however, that all equipment does not work this way. For example,
Dynapac's model 8 (8 port) switch does just what is described in
the message, ie, if it has been optioned to create extended call
accept packets for an attached DTE that cannot do so, it will
take the called address as it saw it and recreate it in the
extended accept packet.  So, no help there, I'm afraid.

In such cases where the calling DTE's software (or the DCE node that
it's connected to) compares the called address in the call request
packet to the called address in the extended call accept packet,
then extended call accept packets have to be disabled at the called
end (since we know that the normal short form of the call accept
packet is acceptable [normally] by all).  

This is, of course, unfortunate since one shouldn't have to disable a
possibly desirable feature because there are certain networks or
pieces of equipment that don't support them.

C'est la vie!

chris 	(Chris Rohrer @ Corporation for Open Systems)
rob 	(Rob Clark @ Corporation for Open Systems)
	-- X@cos.com
	-- X%cos.com@uunet.uu.net
	-- {uunet, sundc, decuac, hqda-ai, hadron}!cos!X

	where X = "chris" or "rob"

george@ditmela.oz (George michaelson) (02/06/88)

Further to this saga, AUSTPAC were finally contacted and enabled 
a feature whereby they *DO* pass up the full called DTE in incoming 
CR packets, and also inserted them on outgoing CC and CR.

However there remained a small snag. They pass in a DTE with a 
leading 0 thus generating 15 digit DTE's... and the sun being called 
can only declare itself to be a 14 digit address. This can be 
circumvented by using 1 digit subaddress routing but I regard that 
as a big kludge. 

AUSTPAC may be legally ok in adding the 0 but surely the DNIC identifies 
external routing directly, and thus guarantees an address can be resolved 
as net-internal or X.75 routed. Why do they do this?

How many programs out there assume the first 4 digits are DNIC?

To get round this we declared the sun as having a NULL DTE (which is a
documented feature for TRANSPAC like networks), and rely on the switch to
correctly route processes into the host. To separate out X25 applications
(such as FTAM and our ISODE process) we can declare any DTE  we like from
homebrew or sourcecode available programs. Thus there is a limit of 9 
identities (subaddress 0 being dubious) per host but the machine would die 
before we reached that anyhow. 

Don't ask why PID masks or CUDF don't work, the switch and the sun 
between them cannot agree on what to do there. The switch can't even 
*specify* the  PID field of CUDF. The sun should be able to route calls
on CUDF and should NOT pass X.29 to X.25 listeners. I think it's broken.

Further the sun supplied pad program and other utilities make use 
of an ioctl (on the X.25 socket they open) to read the local DTE 
(from a config file) for assertion in outgoing calls. Thus the 
machine can have only a SINGLE declared DTE for all applications, 
and cannot be dual-ported into two different address spaces. 

The latter is a major headache for users of IPSS and JANET in the UK 
but could cause problems for sites using a local X25 switch with 
local address space as well as direct X25 connections to the outside 
world from some hosts.

The switch is certainly broken.  Enabling local DTE masking 
(where it fakes a given DTE on all outgoing calls taking only their 
subaddress where given) causes the incorrect DTE to be changed in call 
accept packets, it is unable to explicitly modify *as different objects* 
ALL addresses in ALL packets passed in either direction. it cannot route
on PID. 

I received a local followup (from within australia that is) suggesting 
others have seen this problem. That one was involving DATAPAC (canada?) 
and was solved quite quickly.

Do all networks ending in -PAC derive from common code? AUSTPAC is
TRANSPAC derived.

	it would seem we still have a wee way to go with X25.

-- 
ACSnet:	G.Michaelson@ditmela.oz.au
Postal:	55 Barry St, Carlton, Vic 3053
Phone:	(03) 347 8644 				Fax:	(03) 347 8987