view release on metacpan or  search on metacpan

extra_docs/af-saa-0069.000.txt  view on Meta::CPAN

ATM Forum Technical Committee, “ATM User-Network Interface (UNI) 
Specification, Version 3.1”, ISBN 0-13-393828-X, ATM Forum, 1994  

[BSD4.3]  S. J. Leffler, M. K. McKusick, M. Karels,
The Design and Implementation of the 4.3 BSD Unix Operating System, 1989

[RFC1034]
P. Mockapetris, "Domain Names - Concepts and Facilities", RFC 
USC/Information Sciences Institute, November 1987.

[RFC1035]
P. Mockapetris, "Domain Names - Implementation and Specification", RFC 1035, 
USC/Information Sciences Institute, November 1987.

[RFC1700]
J. Reynolds and J. Postel, "Assigned Numbers", RFC 1700, ISI, October 1994.

[RFC1706]
B. Manning and R. Colella, "DNS NSAP Resource Records", RFC 1706, 
ISI/NIST, October 1994.


?????????A? Requirements 

This informative appendix captures the SAA/DS working group’s requirements.
??1 Basing of ANS on DNS
 
 The ANS is based on the Domain Name Service (DNS) [RFC1034], 
[RFC1035].  Subsequent versions may include IETF enhancements for  
security, dynamic updates, prompt notification of zone changes and 
incremental zone transfer capability extensions.  There are many reasons 
to use DNS as the basis for ANS.
 
I. DNS is widely implemented in end systems.
II. DNS domain registration procedure has been implemented in most 
countries.
III. DNS domain names are well known by the user community.
IV. DNS can scale well if the name space is properly assigned. This 
satisfies the scalability requirement given in A.2.
V. DNS implementations are efficient in terms of CPU and memory 
usage.  This satisfies the efficiency requirement given in A.2.
VI. DNS is resilient via the secondary server mechanism. This satisfies 
the no single point of failure requirement given in A.2.
VII. DNS has low latency of queries. This satisfies the requirement 
given in 2.1.4.
VIII. DNS extensions for dynamic updates and security are being 
worked on.
IX. DNS can be easily augmented with new database objects for ATM.
X. DNS allows dual hosts to choose between IP and native ATM.
??? ANS requirements  
 
 Several requirements for the directory service function that apply to ANS are:
 
? No single point of failure (resilience)
? efficient implementation including storage efficiency
? Hierarchical naming structure (scalability)
? low latency of queries
? Toleration of temporary inconsistency, that is, that such 
inconsistency does not damage the information in ANS.
? The service may sometimes be transiently unavailability, for 
example, “a busy signal” 
 
 Other ANS requirements include:
 
? Independence between non-ATM network and transport layer 
protocols 
 
 ANS is to be used by ATM applications.  These applications may 
not necessarily implement non-ATM network or transport 
protocols.  Most current DNS implementations carry DNS protocol 
messages on top of UDP/IP and TCP/IP.  This document specifies 
the operation of DNS protocols using native ATM services  instead 
of TCP/IP. 
 
? Use of an existing naming scheme 
 
 ANS should exploit an already existing naming scheme in the 
same way as ATM addressing utilizes existing addressing 
schemes.  Otherwise the ATM Forum would need to setup a new, 
worldwide name registration service, which would be a difficult 
task to manage and operate.  Examples of existing naming schemes 
are the Internet’s DNS domain name hierarchy and X.500’s 
directory information tree hierarchy.
 
? Dynamic updating of the directory data base
 
 When an ATM end system address changes, it is important that the 
ANS database need not be manually reconfigured.  The end system 
should be able to dynamically check and update its address 
information in the ANS database.  This is especially important 
when the end user does not even necessarily know that an ATM 
address of the end system has changed.  (For example, a manager 
of the switch could change the address prefix without notifying the 
users.) 
? Security of the dynamic updating process
 
 Dynamic updating of the ANS database by end systems usually 
requires that the updates can be authenticated. ANS must therefore 
include an option to sign the ANS database entries with 
cryptographic digital signatures.  It would also be desirable if ANS 
could store authenticated public keys in its database in order to 
make the ANS protocol independent of yet another public key 
management protocol.
 
? Automatic configuration of ANS clients
 
Finally, automatic configuration of ANS clients is an important 
requirement.  In order to use directory services, the clients need to 
know one or more ATM addresses of one or more ANS servers. If 
security is implemented, an ANS client needs a correct public key 
of at least one zone of the hierarchical name space.  A natural 
solution is that ANS clients learn this information dynamically 
from an ATM configuration server.

?????????B? API Interface to ANS

This informative appendix shows an example or a BSD 4.3 compliant application 
program interface for ANS.

??? BSD 4.3 conformant interface
????? Specifications