tozz@hpindda.HP.COM (Bob Tausworthe) (06/06/89)
I was recently re-reading for the umpteenth time the various addressing
specifications relating to ISO addresses and the following questions came
up. Any information on them would be most helpful.
1) 1984 X.25 extended address facility
ISO 8208, in its description of the Extended Address Facilities
for called and calling address specify two methods to carry NSAP
addresses, FULL NSAPS, and PARTIAL NSAPS. I assume that in the
case of the PARTIAL NSAP the extended address is combined somehow
with the corresponding X.121 address (i.e. if this is the called
address the called extended address is combined with the called
X.121 address) to produce a complete NSAP. What is the algorithm
to carry this out? Is the extendec portion taked to be the IDP
and the X.121 address the DSP? Is the extended portion defined to
be the DSP, the X.121 address is defined to be the IDI, and the
AFI is implied (i.e. CCITT X.121 format)?
A related question: the extended address facility also has a
method for carrying a non-OSI address (called or calling). Has the
addressing domain for this non-OSI address be specified? Is it
X.121?
2) ISO 8473/DAD2 SNDCF for X.25 (8208)
This document outlines the Subnetwork Dependent convergence Function
to be used when providing CLNP over an X.25 subnetwork. Although the
SNDCF for 802.2 specifically states that the subnetwork address is to
be in the MAC domain, the SNDCF for X.25 does not state that the
subnetwork address is to be in the X.121 domain. I assume that it is,
since the Extended address facilities are not specified as required
in the spec. Is it true that the Extended Address Facility should not
be used to convey the subnetwork address when implementing the X.25
SNDCF? Can the non-OSI extended address facility be used?
Is this stated explictly anywhere?
3) binary vs decimal AFI portion of NSAPs: A question of semantics
8348/DAD2, "the NSAP paper" defines how NSAPs are structured.
In it it says the following about this structure: "The conceptual
structure of NSAP addresses follows the principle that, at any level
of the hierarchy, an initial part of the address unambigously identifies
a subdomain, and the rest is allocated by the management of the subdomain
to unambigouusly identify either a lower level subdomain or an NSAP
within the subdomain."
So we see that, conceptually, a leading prefix of a NSAP identifies
a set of NSAPs, grouped together by the adiminstration authority
represented by the prefix.
However, later in the document, two abstract syntaxes for NSAPs are
discussed and unique AFI values are allocated for each syntax for
each IDI format. For instance, IDI format X.121 has an AFI value of 36
for the Decimal syntax, and an AFI value of 37 for the Binary syntax.
What's more, the syntax of the NSAP is part of the semantic definition:
"The Authority and Format Identifier specifies:... the abstract syntax
of the DSP."
The problem is that a machine can have two encodings of the same
information. And there seems to be a difference of opinions in the
ISO community as to whether an NSAP should be processed based on
its semantics or its syntax. For instance, The GOSIP agreements say
that an NSAP is to be treated as a flat string, so they are using
an NSAP strictly on its syntactical merits; two NSAPs are deemed
not-equal if their syntactic values are not-equal. ISO 9542, the ES-IS
routing protocol also treates NSAPs as flat strings. This is seen best
in their use of an address mask. The address mask establishes an
equivalence class of NSAP addresses to which the same Redirect informatoin
applies. The decision criteria for the equivalence class is a logical-and
with the NSAP and a bitmask.
Of course, the problem is that, if a machine's NSAP is conveyed
in two different syntaxes, it will be viewed a two separate NSAPs.
Or worse yet, that two machines could have the same semantic information,
but have two distinct NSAPs, one binary , one decimal.
Is this in line with other peolple's conceptual view of NSAPs? Am I
missing something in the NSAP definition which will prevent things
like the above from occurring?
bob tausworthe
tozz@hpda.hp.com