Path: utzoo!utgpu!watserv1!watmath!att!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!brutus.cs.uiuc.edu!apple!agate!ucbvax!EMU.NCSL.NIST.GOV!colella
From: colella@EMU.NCSL.NIST.GOV (Richard Colella)
Newsgroups: comp.protocols.iso.dev-environ
Subject: Re:  Encoding RFC 1006 addresses in X.500
Message-ID: <9001122056.AA24750@emu.ncsl.nist.gov>
Date: 12 Jan 90 20:56:15 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: inet
Organization: National Institute of Standards and Technology (NIST)
Lines: 98


Bob,

> 
> If I recieve a Presentation Address from Quipu (or any other X.500)
> which has an NSAP component with a prefix of 540072872203, can I assume
> that this is an encoding of a RFC 1006 address?
> 
> Is there another method for encoding RFC 1006 addresses into NSAPs, or
> for  storing them in naming services such as X.500?
> 
> 		       Bob Tausworthe
> 		       tozz@hpda.hp.com
> 

Even as I saw your question we were putting together a similar query
with a proposal.  I believe it's a more formal representation of
NSAP discrimination.  To wit:

My reading of rfc1006 is that it provides a mechanism for running OSI
upper layers over TCP/IP.  It *does not* say anything about the
semantics of information exchanged by the upper layers.  For example,
In ISO 9594 (The Directory), Referrals and DSAReferrals include a
PresentationAddress as part of the AccessPoint through which the
referred DSA/DUA may contact the DSA to which it has been referred.
This information is carried around by the Directory protocol as
PresentationAddresses.  PresentationAddress is defined as follows :

	PresentationAddress ::= SEQUENCE{

                pSelector   [0]     OCTET STRING OPTIONAL,
                sSelector   [1]     OCTET STRING OPTIONAL,
                tSelector   [2]     OCTET STRING OPTIONAL,
                nAddresses  [3]     SET SIZE (1..MAX) OF OCTET STRING}

The nAddresses field contains NSAPs as defined in ISO 8348/ADD 2, the
network layer addressing addendum to the network service definition.
NSAPs look like:

    +------------------------------------------+
    |AFI|IDI|                DSP               |
    +------------------------------------------+

where:  AFI - authority and format identifier
        IDI - initial domain identifier
        DSP - domain specific part

The AFI (effectively) defines the rest of the NSAP structure.  All AFI
values (of which there are 100) are either assigned (of which there are
24), reserved never to be allocated (of which there are 10), or
reserved for later use (the rest).

Assume that we are operating in a mixed OSI/TCP lower layers
environment.  Now, if my DSA wants to send your DUA a referral that
contains a non-OSI "NSAP", how do I put it into the nAddresses
element:

        1) without violating the protocol by changing the
           PresentationAddress structure (I still want to
           interoperate with pure OSI boxes), and,
        2) allowing as transparent operation as possible for upper
           layer entities (like the DSA and DUA we are building).

So far, our (best) solution (kludge?) is to hijack one of the "reserved
for later use" AFI fields.  That way, information could be held and
exchanged among DSAs and DUAs (and other layer 7 entities) in the
format prescribed in 9594, but could be interpreted and used correctly
by the lower layers in ESs that are "in the know". For those ESs with
lower layers not "in the know", attempts to use the NSAP would result
in an "unsupported NSAP" error from the underlying lower layers (which
is the expected behavior with unsupported NSAPs).  The advantages of
this approach are that it would work for the experimental environment
and would allow us to interoperate between pure OSI and rfc1006
environments pretty transparently.  The disadvantages are that we are
being non-conformant wrt OSI and the AFI value we hijack *could* be
allocated out from under us (not very likely, I think).

An alternative would be to do the same thing as above, but use the
"local" AFI value of 49.  However, local means just that.  It should be
used in closed environments, which is not what we are about.  It is
possible that a value we choose under local (and are using non-locally)
conflicts with a value someone else has chosen under local (and is also
using non-locally).

This is back-of-the-envelope reasoning---anybody have any better ideas?

Regards,
Richard

P.S.- I haven't seen Steve Kille's "An Interim Approach to the use of
Network Addresses"; where can I get it (Steve?) and what is it about?

+---------------------------------------------------------------------------+
| Richard Colella                                                           |
| colella@osi3.ncsl.nist.gov National Institute of Standards and Technology |
| (301) 975-3614             Technology Building, B217                      |
| Fax: (301) 590-0932        Gaithersburg, MD 20899                         |
+---------------------------------------------------------------------------+