Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!usc!ucsd!ucbvax!hplabs!hpcc01!hpcuhb!hpindda!tozz
From: tozz@hpindda.HP.COM (Bob Tausworthe)
Newsgroups: comp.protocols.iso
Subject: Re: Transport & Network addressing over TLI
Message-ID: <5560057@hpindda.HP.COM>
Date: 9 Apr 90 23:36:43 GMT
References: <791@oz.rci.dk>
Organization: HP Information Networks, Cupertino, CA
Lines: 78

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