view release on metacpan or  search on metacpan

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

The receipt or any use of this document or its contents does not in any way create by implication otherwise:

•	Any express or implied license or right to or under any ATM Forum member company's patent, copyright, 
trademark or trade secret rights which are or may be associated with the ideas, techniques, concepts or 
expressions contained herein; nor

•	Any warranty or representation that any ATM Forum member companies will announce any product(s) and/or 
service(s) related thereto, or if such announcements are made, that such announced product(s) and/or service(s) 
embody any or all of the ideas, technologies, or concepts contained herein; nor

•	Any form of relationship between any ATM Forum member companies and the recipient or user of this 
document.

Implementation or use of specific ATM standards or recommendations and ATM Forum specifications will be 
voluntary, and no company shall agree or be obliged to implement them by virtue of participation in The ATM 
Forum.

The ATM Forum is a non-profit international organization accelerating industry cooperation on ATM technology.  
The ATM Forum does not, expressly or otherwise, endorse or promote any specific products or services.

NOTE:  The user's attention is called to the possibility that implementation of the ATM interoperability specification 
contained herein may require use of an invention covered by patent rights held by ATM Forum Member companies 
or others.  By publication of this ATM interoperability specification, no position is taken by  The ATM Forum with 
respect to validity of any patent claims or of any patent rights related thereto or the ability to obtain the license to 
use such rights.  ATM Forum Member companies agree to grant licenses under the relevant patents they own on 
reasonable and nondiscriminatory terms and conditions to applicants desiring to obtain such a license.  For 
additional information contact:

The ATM Forum
Worldwide Headquarters
2570 West El Camino Real
Suite 304
Mountain View, CA 94040
Tel:    +1-415-949-6700
Fax:    +1-415-949-6705

Contents
1. INTRODUCTION	1
2. TERMS AND DEFINITIONS	1
3. OVERVIEW OF ANS	1
4. LOGICAL MODELS	2
5. DATABASE ELEMENTS	2
5.1 RESOURCE RECORD DEFINITIONS	2
5.2 ATM SPECIFIC RESOURCE RECORDS	2
5.3 ATM ADDRESS TO DOMAIN NAME MAPPING	3
5.4 EXAMPLE MASTER FILE FORMAT	5
6. DNS PROTOCOL IN ATM ENVIRONMENT	6
6.1 RECURSIVE PROCESSING	7
6.2 CLIENT INITIALIZATION	7
6.3 CONNECTION USAGE	7
7. NATIVE ATM SERVICES INTERFACE	7
8. ATM DIRECTORY SERVICE INTERFACE	9
9. REFERENCES	9
APPENDIX A: REQUIREMENTS	10
A.1 Basing of ANS on DNS	10
A.2 ANS requirements	10
APPENDIX B: API INTERFACE TO ANS	12
B.1 BSD 4.3 CONFORMANT INTERFACE	12
B.1.1 Specifications	12
B.1.2 IPng aligned interface	14
B.1.3 WinSock 2 aligned interface	14



1. Introduction
 ATM applications require various types of directory services.  Directory services 
can be universal, that is, used by more than one application,  or they may be 
application specific.  An example of a universal directory service is finding an 
ATM address corresponding to the name of an ATM end system.  An example of 
an application specific service is finding the  providers of specific types of 
services (for example, Video on Demand servers).  
 
 ATM Name System (ANS) is an extension to the Internet Engineering Task Force’s 
(IETF) Domain Name System (DNS).  However, rather than running on top of 
TCP/IP or UDP/IP like most DNS implementations, ANS is a native ATM 
application.  As such, ANS uses an API whose semantics are specified in 
[ATMNAS] to gain access to the ATM network via ATM Forum UNI signaling.  
The ANS record formats and DNS functions are intended to be independent of the 
version of the underlying ATM signaling.  See [ATMNAS] for information on the 
versions of the UNI signaling that are applicable to ANS.
 
 ANS clients use ATM SVCs to communicate to their ANS servers.  ANS version 1.0 
servers use ATM SVCs or UDP to communicate ANS queries and replies to other 
ANS servers.  ANS version 1.0 servers use TCP to communicate reliable zone 
transfer messages.        
 
Basic name services are modeled on the Domain Name System [RFC1034,  
RFC1035].  Some extensions that may be considered for version 2.0 are security 
extensions, dynamic update capability, mechanisms for prompt notification of 
zone changes, and incremental zone transfer capability.

The basic directory services are domain name to ATM address translation and 
ATM address to domain name translation.  The domain name to ATM address 
translation is performed under existing top level domain names.  The ATM 
address to domain name translation is done using a new domain name of 
ATMA.INT.  However, information other than ATM names and addresses may be 
added to the ANS data base.  The ATM Forum (ATMF) supports rapid 
deployment of the essential name services and  provides infrastructure for higher 
level directory services.
 
 This specification is version 1.0 of the ATM Name System (ANS) and includes the basic 
functionality as defined in [RFC1034] and [RFC1035].  Since ANS is based on 
DNS, the SAA/DS group decided to refer to [RFC1034] and [RFC1035] rather 
than repeat information contained in these RFCs in this specification.  
Implementers will need to refer to these documents.
    
2. Terms and Definitions
 
 See [RFC1034] and [RFC1035] for DNS terms and definitions.
 
3. Overview of ANS 
 
 See [RFC1034] and [RFC1035] for an overview of DNS.
 
4. Logical models
 
 See section 2.2 of [RFC1035] for common DNS configurations.
 
5. Database elements 
 

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

	  char **h_addr_list;	/* list of addresses from nameserver */
	};

#define h_addr h_addr_list[0] /* address, for backward compatibility */

The members of this structure are:

	h_name	Official name of the host.

	h_aliases	A zero terminated array of alternate names for the host.

	h_addrtype	The type of address being returned

	h_length	The length, in bytes, of the address.

	h_addr_list	A  zero terminated array of network addresses for the host.  Host 	
			addresses are returned in network byte order.

	h_addr	The first address in h_addr_list; this is for backward compatibility.

The sethostent, endhostent, gethostent, and herror calls are not modified. To 
support the remaining two routines the semantics of the structure hostent has to be 
extended by the newly supported address types because the component h_addrtype 
today always carries AF_INET as answer and the type argument of the gethostbyaddr 
function is supposed to be AF_INET in all cases as well. The necessary new specifications 
are two defines:

#define AF_ATMNSAP           3
#define AF_ATME164           8

where the values are usually specified in the file socket.h and should follow [RFC1700] 
as proposed in the definitions above. The call gethostbyname_e164 is supposed to return 
E.164 addresses and gethostbyname_atmnsap ATM-nsap addresses.

The h_length is set to the length of the addresses chained in h_addr_list.

Additionally, if a socket-like form of address conversion from human readable to internal 
forms in the API is supported, some new structures and functions may to be provided as 
existing in today's most BSD 4.3 implementations.

	struct atmnsap_addr
	{
	  char atmnsap[20];
	}
	
	struct atme164_addr
	{
  	  char atme164[20];
	}	

	struct atmnsap_addr *atmnsap_addr(const char *cp);
	char	*atmnsap_ntoa(struct atmnsap_addr in);

	struct atme164_addr *atme164_addr(const char *cp);
	char	*atme164_ntoa(struct atme164_addr in);

The returned and expected human readable strings conform to the form encountered in 
the master file and described in section 5.4. The returned structures must not be freed by 
the application and are not thread-safe.

????? IPng aligned interface

Since introduction of IPv6 included a new addressing scheme, the internet protocol next 
generation (IPNG) work in progress tries to address the issue of a new application 
programmer's interface, specifically of the name-resolving calls beside many others. 
These calls will support address family parameters so functions can be easily 
implemented to support AF_ATMNSAP and AF_ATME164 as well. Extended functions for 
address to ASCII conversions and vice versa translation can also be found in this work.

????? WinSock 2 aligned interface

WinSock 1.1 supported a BSD 4.3 compliant interface for name resolution very much as 
the one described in section B.1.1, so the functions proposed there can be applied as well.  
Version 2 of the specification includes the protocol independent name resolution in the 
current version as an item for further study.




af-saa-0069.000		ATM Name System Specification Version 1.0
ATM Name System Specification Version 1.0	af-saa-0069.000		
Page 16		ATM Forum Technical Committee

ATM Forum Technical Committee		Page  15