RFC1348 - draft of revison

[William Manning <[e-mail]>]

Below is a draft of a revison to RFC 1348.  Richard made most of
the changes which clarified many points of fuzziness on NSAP
handling.  Folks on the Namedroppers list made additional comments,
some of which have not been added.  I claim all the errors.  As always
PLEASE USE THE RED PENCIL.
	-------------------------------------------------------
%
% for the Sun...
%
\documentstyle[11pt,times,internet-draft]{article}
%
\title{DNS NSAP RRs
}
\author{B. Manning (Rice University)}
\address{R. Colella (NIST)}
\pubdate{07 Aug, 1992}
%
%
\begin{document}
%
\bibliographystyle{plain}
%
\maketitle

\vspace{.3in}
{\large Status of This Memo}

This memo refines the approch taken in RFC 1348, updating the
processing methods for encoding of NSAP addresses for the Internet
community.  Discussion and suggestions for improvement are
requested.  Please refer to the current edition of the ``IAB
Official Protocol Standards'' for the standardization state and
status of this protocol.  Distributuion of this memo is unlimited.


\vspace{.3in}
\begin{center}
{\large Abstract}
\end{center}

The Internet is moving towards the deployment of
an OSI lower layers infrastructure.
This infrastructure comprises the connectionless network
protocol (CLNP) and supporting
routing protocols.  Also required as part of this infrastructure
is support in the DNS for mapping between names and NSAP addresses. 

This RFC redefines the format of two new Resource Records
for the Domain Name System, as defined in RFC 1348.
This format may be used with any OSI NSAP address format.

\clearpage
\tableofcontents
\clearpage
%
% Body of article goes here...
%
\section{Introduction}

The Internet is moving towards the deployment of
an OSI lower layers infrastructure.
This infrastructure comprises the connectionless network
protocol (CLNP) \cite{ISO8473} and supporting
routing protocols.  Also required as part of this infrastructure
is support in the Domain Name System (DNS) \cite{RFC1034,RFC1035}
for mapping between DNS names and OSI Network Service Access
Point (NSAP) addresses \cite{ISO8348Ad2}
[Note: NSAP and NSAP address are used interchangeably throughout
this memo].

This memo redefines the format of two new Resource Records (RRs)
for the DNS, as defined in RFC 1348.
This format may be used with any OSI NSAP format.

This memo assumes that the reader is familiar with the DNS.
Some familiarity of NSAPs is useful; see \cite{RFC1237} or
\cite{ISO8348Ad2} for additional information.


\section{Background}

The reason for defining DNS mappings for NSAPs is to support CLNP in
the Internet.  Debugging with CLNP ping and traceroute is becoming more
difficult with only numeric NSAPs as the scale of deployment increases.
Current debugging is supported by
maintaining and exchanging a configuration file with name/NSAP
mappings similar in function to hosts.txt.  This suffers from the
lack of a central coordinator for this file and also from the
perspective of scaling.  The former is the most serious
short-term problem; scaling of a hosts.txt-like solution has well-known
difficiencies.

A second reason for this work is the proposal to use CLNP as
the mid-term replacement for IP:  {\em TCP and UDP with Bigger
Addresses (TUBA), A Simple Proposal for Internet Addressing
and Routing} \cite{RFC1347}.  Should this proposal be selected,
the DNS must be capable of supporting CLNP addresses.


\section{Scope}

The RRs defined in this paper support all known NSAP formats.  In
addition, the RRs support the notion of an Internet-defined NSAP
format.  There are several ways in which the Internet can define its
own format.  For the purposes of this memo, it is assumed that the
Internet will obtain an AFI from ISO and define a fixed-field NSAP
format.

[Note: There is a distinction between registration and publication
of addresses.  For IP addresses, the IANA is the root registration
authority and the DNS a publication method.  For NSAPs, ISO8348/Ad2
is the root registration authority and the DNS is being proposed
as a publication method.  Should this be discussed?]


\section{Structure of NSAPs}		\label{STRUCT}

NSAPs are hierarchically structured to allow distributed
administration and efficient routing.  Distributed administration
permits subdelegated addressing authorities to, as allowed by the
delegator, further structure the portion of the NSAP space under
their delegated control.  Accomodation of this distributed authority
requires flexibility in the DNS representation of NSAPs, allowing
subauthorities to represent the substructure they define, if any, in
the DNS as well as the NSAP values themselves.

While all NSAP structures currently in use in the Internet have fixed
field sizes (e.g., \cite{RFC1237,IPTAG-92-23-PB660}, some NSAP
formats have a variable-size field.  These formats
are still parsable, since the total NSAP length is known and there is, at
most, one variable-sized field.  The scheme described allows this.

For the purposes of this memo, NSAPs can be thought of as a tree of
identifiers.  The root of the tree is defined in Addendum 2 to
ISO8348 \cite{ISO8348Ad2}, and has as its immediately registered subordinates the
one-octet Authority and Format Identifiers (AFIs) defined there.  The
size of subsequently-defined fields depends on which branch of the
tree is taken.  The depth of the tree varies according to the
authority responsible for defining subsequent fields.

An example is the authority under which US GOSIP defines NSAPs
\cite{GOSIPV2FT}.  Under the AFI of 47, NIST (National Institute of Standards
and Technology) obtained a value of 0005
(the AFI of 47 defines the next field as being two octets consisting
of four BCD digits from the International Code Designator space
\cite{ISO6523}).  NIST defined the subsequent fields in
\cite{GOSIPV2FT}.  The field immediately following 0005 is a format
identifier for rest of the US GOSIP NSAP structure, with a hex value of
80.  Following this is the three-octet field, values for which are
allocated to network operators; the registration authority for this field is
delegated to GSA (General Services Administration)

For the purposes of this memo, we will present NSAPs as a string
of ``.''-separated hex values.  The values correspond to the fields
in the NSAP, as defined by the appropriate authority.
For example, a printable representation of the first four
fields of a US GOSIP NSAP might look like

\begin{center}
47.0005.80.005a00
\end{center}

and a full US GOSIP NSAP is

\begin{center}
47.0005.80.005a00.0000.1000.0020.00800a123456.01.
\end{center}

For more information on US GOSIP NSAPs, see RFC1237 \cite{RFC1237}.
Other NSAP formats have different fields and field widths;
see the examples in Section \ref{EXAMPLES} and also \cite{IPTAG-92-23-PB660}.




\section{NSAP RRs Specification}

\subsection{The NSAP RR}

The NSAP RR is defined with mnemonic NSAP and type code 22 (decimal).
The NSAP RR has the following format:

		\begin{center}
	$<owner$> $<ttl$> $<class$> NSAP $<rdata$>
		\end{center}

All fields are required.

The $<owner$> is the DNS name for the system that is addressed
by the NSAP in the $<rdata$> field (see below).

The meaning of the $<ttl$> field is as specified in RFC1034.

The format of the NSAP RR is class insensitive.

The $<rdata$> is a complete NSAP address expressed in the dotted
hexidecimal notation as described in Section \ref{STRUCT}.

[Note: Is there any need to have DNS entries for NSAP prefixes?] 

NSAP RR causes no additional section processing.





\subsection{the NSAP-PTR RR}

The NSAP-PTR RR is defined with mnemonic NSAP-PTR and type code
23 (decimal).  It's function is analogous to the PTR record used
for IP addresses \cite{RFC1035,RFC1101}, although the details
of how it operates are different.
The NSAP-PTR RR has the following format:

		\begin{center}
	$<owner$> $<ttl$> $<class$> NSAP-PTR $<rdata$>
		\end{center}

All fields are required.

The $<owner$> is a complete NSAP or an NSAP prefix.  The octets
of the NSAP are in reverse order, with the least significant
octet on the left and the AFI octet on the right.  The reversal
is on an octet boundary.  The dotted
hexidecimal notation described in Section \ref{STRUCT} is used to
separate the NSAP fields.

The meaning of the $<ttl$> field is as specified in RFC1034.

The format of the NSAP RR is class insensitive.

The $<rdata$> field consists of two subfields separated by one or
more spaces or tabs.  The first subfield is a DNS name that
corresponds to the owner of this NSAP prefix.  In the case of an
incomplete NSAP (i.e., an NSAP prefix), this subfield must name the
root with a single ``.''. [Note: Having something in the subfield
allows easy parsing, but does each entry really need an owner?  If
so, should it be root?].

The second subfield of $<rdata$> contains structure information
for subsequent fields of the NSAP, to the extent that they are
known at this level of the NSAP tree.  Strictly speaking, only
the size of the next field is required to navigate the DNS NSAP
tree.  However, for efficiency the NSAP structure information should
be included as far up towards the root as possible.

The format of this subfield is a set of ``.''-separated decimal
digits representing the sizes of fields subsequent to the NSAP prefix
given in the $<owner$> field.  [Should we have a BNF for this?] A
trailing ``.'' indicates that the structure information is complete.
For leaf entries (i.e., when the $<owner$> contains a complete NSAP),
this subfield must contain a single ``.''.

The NSAP-PTR RR causes additional section processing which is described
in the next section.





\section{DNS Operation for NSAPs}

Name-to-NSAP mapping in the DNS using the NSAP RR operates analogously to IP address
lookup.  A query is generated by the resolver requesting an NSAP RR
for a provided DNS name.

NSAP-to-name mapping using the NSAP-PTR RR differs from the inverse
lookup for IP addresses due to the structure of NSAPs and the requirements
this places on the lookup process.

The NSAP-to-name scheme operates with minimal {\em a priori} knowledge of how NSAPs
are structured and operates according to a simple algorithm.  Given an
NSAP to be resolved, the only {\em a priori} information needed is that the
first field of all NSAPs is one octet.  The basic algorithm operates as follows:

\begin{enumerate}
	\item build an initial query to read the record associated with
		the first octet.

	\item knowledge of the NSAP structure is not complete, so set
		(COMPL-KNOW = FALSE).

	\item send the query.

	\item when the response is returned, if (COMPL-KNOW == TRUE), done.

	\item construct a more detailed query with the additional
		structure information from the response.

	\item if the structure information returned ends with a ``.'',
		then set (COMPL-KNOW = TRUE).

	\item go to step 3.
\end{enumerate}

The {\em a priori} knowledge required is that all NSAPs begin with an
initial one-octet field, the AFI (Authority and Format Identifier,
see \cite{ISO8348Ad2}); this is captured in step 1.

Steps 3 through 7 represent a simple learning algorithm in which the
resolver issues queries that are increasingly detailed until the
result is obtained.

Successful termination, step 4, occures if the last query sent was
based on complete NSAP structure information, as determined by the
tailing ``.''.


\section{Examples}			\label{EXAMPLES}

Three examples are presented.  The first uses US GOSIP NSAPs,
the second a fictitious NSAP structure based on the idea of
an Internet-assigned AFI, and the third demonstrates the
scheme in the presence of a variable-length NSAP field.


\begin{verbatim}
;;;;;;
;;;;;; GOSIP-style NSAP.
;;;;;;

<owner>               <class>   <type>   <rdata>
.                       IN       NSAP     47
.                       IN       NSAP     47.0005
.                       IN       NSAP     47.0005.80
nist.gov                IN       NSAP     47.0005.80.005a00
emu.ncsl.nist.gov       IN       NSAP     (
                47.0005.80.005a00.0000.1000.0020.00800a123456.01)


47                      IN     NSAP-PTR   .  2
0500.47                 IN     NSAP-PTR   .  1
80.0500.47              IN     NSAP-PTR   .  3.2.2.2.6.1.
005a00.80.0500.47       IN     NSAP-PTR   nist.gov  2.2.2.6.1.
01.5634120a8000.2000.0010.0000.005a00.80.0500.47
                        IN     NSAP-PTR   emu.ncsl.nist.gov  .)


;;;;;;
;;;;;; Internet AFI-based NSAP.
;;;;;;
;
; Assume XX is the Internet AFI, and XX-based NSAPs have
; a fixed 19-byte format:
;        1.1.3.3.4.6.1.
; where the numbers indicate field sizes in octets.
;

<owner>               <class>   <type>   <rdata>
.                       IN       NSAP     XX
.                       IN       NSAP     XX.12
bb                      IN       NSAP     XX.12.123456
reg.bb                  IN       NSAP     XX.12.123456.151617
host.reg.bb             IN       NSAP     (
                XX.12.123456.151617.37383930.414243454647.89)


XX                      IN     NSAP-PTR   .  1.3.3.4.6.1.
12.XX                   IN     NSAP-PTR   .  3.3.4.6.1.
563412.12.XX            IN     NSAP-PTR   bb  3.4.6.1.
171615.563412.12.XX     IN     NSAP-PTR   reg.bb  4.6.1.
89.474645434241.30393837.171615.563412.12.XX  (
                        IN     NSAP-PTR   host.reg.bb  .)



;;;;;;
;;;;;; NSAP with variable-size field.
;;;;;;
;
; An example of an NSAP format with a variable field size.
; The example is of an X.121 NSAP.
;


<owner>               <class>   <type>   <rdata>
.                       IN       NSAP    37
one-org.com             IN       NSAP    37.31342023011007.01
two-org.com             IN       NSAP    37.575654012456.03

37                      IN     NSAP-PTR  com  *.1.
01.07100123203431.37    IN     NSAP-PTR  one-org.com  .
03.562401545657.37      IN     NSAP-PTR  two-org.com  .
\end{verbatim}


\section{Security}

Security issues are not addressed in this memo.

\section{Authors' Addresses}

Bill Manning\\
Rice University -- ONCS\\
P.O. Box 1892\\
6100 South Main\\
Houston, Texas  77251-1892\\
USA\\
\ \\
Phone: [phone]\\
EMail: [e-mail]\\
\ \\
\ \\
Richard Colella\\
National Institute of Standards and Technology\\
Technology/B217\\
Gaithersburg, MD  20899\\
USA\\
\ \\
Phone: [phone] (voice); [phone] (fax)\\
EMail: [e-mail] (Internet)\\
\hspace{.2in}/C=us/A=attmail/P=gov+nist-gw/S=colella/ (X.400)


\appendix

\section{Issues}

\subsection{User Interfaces}

Typical user interfaces, for example nslookup, expect the inverse map
string to be typed from least significant byte to most significant
byte followed by IN-ADDR.ARPA.  This isn't too bad for four-byte
IP addresses, but can be excruciating for 20-byte NSAPs.  It would
be much easier if this reversal could be done by the software
instead of the user.  This is especially true since one convenient
way to handle NSAPs is by picking and stuffing values.  So, if we
have an NSAP,

\begin{center}
47000580005a0000001000002000800a12345601
\end{center}

One would like to pick it, stuff it on a command line (e.g., to nslookup),
and append NSAP-PTR.ARPA.:

\begin{center}
\% nslookup 47000580005a0000001000002000800a12345601.NSAP-PTR.ARPA.
\end{center}

The resolver code could recognize the NSAP-PTR.ARPA domain and perform
the appropriate reversal.

\subsection{Owner of Topmost Prefixes}

Who should the owner be for the topmost prefixes, e.g., 47 and 47.0005?
We have presumed it is root.

\subsection{Structure Information}

Should the rdata information for NSAP-PTR always include structure
information for consistency?  There are two cases.  First, when
the higher level contains all known NSAP field sizes, this information
is redundant, but could be included (this is the way we have shown it).
Second, the leaf nodes need no structure information in the rdata, but
could include a single ``.'' to mean there is no more.

\subsection{Nselectors}

Should Nselectors be included in the leaf entries?  We believe the
answer is yes.  How might we handle multiple Nselectors for the same
system, where the only difference between NSAPs is in the Nselector?

\subsection{Relationship to X.500}

It may be useful to associate an X.500 distinguished name with
an NSAP.  Some thought should be given to whether this is useful
and how it could be done.


\bibliography{/usr/local/npg/latex}

\end{document}

	-------------------------------------------------------
-- 
Regards,
Bill Manning         [e-mail]        PO Box 1892
 713-285-5415         713-527-6099	       Houston, Texas
   R.U. (o-kome)       			        77251-1892