ofl@oz.rci.dk (Ole Frank Larsen) (03/29/90)
I have a question regarding transport addressing over TLI. The system
concerned is an Interactive Systems Corp. 386/ix 2.0.2 (System V.3.2).
Imagine that you have a transport provider (TP) running above an X.25
network provider (NP). The TP offers a TLI interface to the Transport
User.
The question is: What format should the Transport addresses (TSAP
addresses) for the TP have? TLI does not specify the format of
addresses.
I understand that Retix uses the following format:
<nlg><NSAP address><tlg><TSAP selector>
<nlg> Length of the NSAP address field.
<Network address> NSAP address encoded according to
ISO 8348/Addendum 2.
<tlg> Length of the TSAP selector field.
<TSAP selector> The TSAP selecor identifying the TSAP.
Is this *the* format of a TSAP address?
If it is, then what is the format of the NSAP address? I am familiar
with ISO 8348/Addendum 2 which specifies an NSAP address as an IDP
followed by an DSP, the IDP consisting of an AFI and an IDI.
The problem is that the TP runs above an *X.25* network provider.
X.25 only allows called address to be a 14-octet X.121 address, unless
the extended addressing facility is used. The X.121 addresses do NOT
conform to ISO 8348/Addendum 2.
If the TP allows both 14-octet X.121 addresses and full NSAP addresses
to appear in the NSAP address field of the TSAP address, then how does
the TP distinguish between the two? It *must* be able to tell whether
a given address is a full NSAP address or merely an X.121 address,
because the former should be entered in the extended addressing
facility field of the X.25 packet whereas the X.121 address should be
entered in the called address field.
Is the answer that only full NSAP addresses are allowed?
Any help will be greatly appreciated. If you respond through e-mail,
i'll post a summary (Promise!).
Best Regards
--
Ole Frank Larsen. RC International, Denmark
ofl@rci.dk Hackers do it with fewer instructionstozz@hpindda.HP.COM (Bob Tausworthe) (04/10/90)
> / hpindda:comp.protocols.iso / ms6b+@ANDREW.CMU.EDU (Marvin Sirbu) / 10:12 am Mar 30, 1990 / > > I believe the answer to your question is the following: > X.25(1984) is NOT conformant with the OSI standard for the CONS, in part > because it does not support NSAP addressing. The 1988 revisions to X.25 > have modified it to become a complete CONS, with support for NSAP > addresses. Check the CCITT Blue Book for X.25(1988). > > I was under the impression that X.25 (1984) WAS conformant with the OSI standard for CONS. That's what the Caller/Called Extended Address facility sets are for. The key ISO document which describes the mapping of CONS onto X.25 is ISO 8878, "Use of X.25 to provide the OSI connection-oriented network service." In it, it describes how to get fully map CONS onto X.25 (1984). It also includes a SNDCP for providing an approved subset of CONS over X.25 (1980) [this is the infamous ISO 8878 Annex A]. The way the SNDCP works is: 1) A unique PID value is allocated for the SNDCP which is different from the CONS PID. Therefore the caller must know that it is talking to a system which doesn't support the full CONS, but does support the SNDCP. 2) The SNDCP simulates the missing facilities needed by 8878 by using either the fast select facility (if present) or the first few data packets as protocol packets and encodes the information into what it calls PT and PV fields. Its not perfect (not by a long shot!) and usually requires that the caller have a great deal of a priori information (e.g. 1980 v.s. 1985, does remote support fast select, does remote support Q-bit . . .). It does, however, provide a way to get close to CONS in 1980 networks in a legal way. In answer to the origional question, the following excerpt from 8878 may shed some light: Section 6.2.2.2.1 Absent AEF [Address Extension Facility] case If the AEF is not present [no NSAP], then local knowledge is required by the receiving NL [network layer] entity to determine whether an OSI NSAP Address is to be deduced from the content of the AF [i.e. X.121 address]. If local knowledge indicates that an NSAP Address is present, its abstract syntax is as follows: a. the AfI is deduced from knowledge of the subnetwork from which the packet was received. b. the IDI is the same as the contents of the AF; and c. the DSP is absent. Essentially this all boils down to: - in general X.121 addresses are SUBNETWORK addresses, not INTERNET addresses. NSAPs are the internet addresses - the Address extension facility is the prescribed method to convey the INTERNET address between the network layer entities. In 1980 X.25 networks, the missing facilities are simulated by use of an SNDCP. - If, however, the AEF is not present, NSAPS may still be conveyed if the NSAP can be algorithmically determined from the X.121 SUBNETWORK address. Interestingly enough, clause 6.2.2.2.1 provides an easy method to get minimal CONS support from 1980 X.25 without having to implement the SNDCP: Use the X.121 address as the NSAP. In other words, in those situations where CONS is to communicate with a 1980 X.25 implmentation, simply leave out the AEFs entirely and perform the rest of 8878 as much as possible. The calling and called NSAPs are implied by the calling/called X.121 addresses. I realize that this sounds somewhat like cheating, but everybody does it. Our current X.400 product communicates over 1980 X.25 this way and we interoperate with several vendors (sun, ATT...). Bob Tausworthe Hewlett Packard ------------------------ Warning: These opinions are my own