[prev in list] [next in list] [prev in thread] [next in thread]
List: namedroppers
Subject: Liaison from ATM Forum
From: George Dobrowski <ghd () CC ! BELLCORE ! COM>
Date: 1996-03-15 17:07:26
[Download RAW message or body]
To: IETF
Randy Bush
email: randy@psg.com
Chair DNSIND
email: namedroppers@internic.net
Subject: Liaison on DNS Class Name, Class Code Point, and Domain Name for
ATM Name Service (ANS) Baseline Document
The ATM Forum's Service Aspects and Applications (SAA)/Directory Service (DS)
group is developing an ATM Name Service (ANS) specification containing
references to a DNS Class ATM and a DNS domain ATM.INT.
The ATM Forum has decided to use the Domain Name Sustem (DNS) [RFC1034,
RFC1035] for mapping names to ATM resources. According to section 3.6 of
RFC1035, we request a new Class name ATM. To support this class we require
a Class code point for the ATM Class protocol family. We also request that
ATM.INT be allocated as the Domain Name.
From: George Dobrowski
Chair ATM Forum Technical Committee
CC: SAA/DS Working Group
Attached for your reference is a copy of the current ANS baseline text. The
information contained represents work in progress and is subject to change
after more study and comments. It is offered for discussion in the interest
of maximizing the availability of interoperable equipment and services.
--------------------------------------------------------------------------------
ATM Forum: Technical Committee, SAA/Directory
ATM Forum/95-1532R2
Straw Vote
April 15-19, 1994
************************************************************
Title: ATM Name Service (ANS) Base Text
************************************************************
Abstract: Base text for version 1.0 of the ATM Name Service (ANS) is
presented. ANS is based on IETF's Domain Name Service (DNS) and provides
name to ATM address resolution and ATM address to name resolution. Version
0 of the ANS includes the basic functionality as defined in [RFC1034] and
[RCF1035] without their proposed extensions. These extensions would then be
part of version 2, which we would start working on after version 1 has been
finalized.
************************************************************
Date: April 15-19, 1996.
Anchorage, AK, USA
Distribution: ATM SAA
************************************************************
NOTICE
This document is offered to The ATM Forum membership as a basis for
discussion and is not binding on IBM or on any other member organization.
The requirements, specifications, proposals, comments or other material
presented herein are subject to change in form and content after further study.
IBM specifically reserves the right to add to, amend, or withdraw material
contained herein.
Technical Committee
ATM Name System (ANS)
Specification
Version 1.0
ATM Forum/95-1532R2
Straw Vote Version
April 1996
ATM Name System
Version 1.0
April 1996
O1996 The ATM Forum. All Rights Reserved. No part of this publication may be
reproduced in any form or by any means.
The information in this publication is believed to be accurate as of its publication date.
Such information is subject to change without notice and the ATM Forum is not
responsible for any errors. The ATM Forum does not assume any responsibility to update
or correct any information in this publication. Notwithstanding anything to the contrary,
neither The ATM Forum nor the publisher make any representation or warranty,
expressed or implied, concerning the completeness, accuracy, or applicability of any
information contained in this publication. No liability of any kind shall be assumed by The
ATM Forum or the publisher as a result of reliance upon any information contained in this
publication.
The receipt or any use of this document or its contents does not in any way create by
implication or 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.
Table of Contents
1. INTRODUCTION 5
1.1. MOTIVATION 5
2. TERMS AND DEFINITIONS 5
3. OVERVIEW OF ANS 5
4. LOGICAL MODELS 6
5. DATABASE ELEMENTS 6
5.1. RESOURCE RECORD DEFINITIONS 6
5.2. ATM SPECIFIC RESOURCE RECORDS 6
5.3. ATM ADDRESS TO DOMAIN NAME MAPPING 7
5.4. EXAMPLE MASTER FILE FORMAT 8
6. DNS PROTOCOL IN ATM ENVIRONMENT 9
6.1. RECURSIVE PROCESSING 9
6.2. INITIALIZATION 10
6.3. CLIENT INITIALIZATION 10
6.4. CONNECTION USAGE 10
7. NATIVE ATM SERVICES INTERFACE 11
8. ATM DIRECTORY SERVICE INTERFACE 11
9. REFERENCES 11
10. APPENDIX 1 - EXAMPLE ANS API 12
11. APPENDIX 2 - REQUIREMENTS 14
11.1. BASING OF ANS ON DNS 14
11.2. ANS REQUIREMENTS 15
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, VoD servers).
This document is version 1.0 of the ATM Name System (ANS). ANS is based on
Domain Name System (DNS) [RFC1034, RCF1035]. Among other functions,
DNS provides name to address and address to name resolution. ANS provides
name to ATM address resolution and ATM address to name resolution. Version
1.0 of the ANS includes the basic functionality as defined in [RFC1034] and
[RCF1035]. Future IETF extensions may become part of subsequent versions of
ANS.
1.1. Motivation
Basic name services are modeled on the Domain Name System [RFC1034,
RFC1035]. Extensions that may be considered are as follows: [DNSSEC]
describes security extensions. [DNSDYN] describes dynamic update capability.
[DNSNOT] describes a mechanism for prompt notification of zone changes.
[DNSIZT] describes incremental zone transfer capability.
The basic directory services are name to ATM address translation and ATM
address to name translation. However, information other than ATM names and
addresses may be added to the ANS data base. The ATMF supports rapid
deployment of the essential name services and provides infrastructure for higher
level directory services.
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
5.1. Resource Record Definitions
ATM specific resource records (RR) conform to the top level RR format and
semantics as defined in Section 3.2.1 of [RFC1035].
An RR CLASS code is needed to identify the ATM protocol family. This code
point is 0xzzzz.
<editor's note: A liasion with the IETF to obtain this codepoint is underway.>
5.2. ATM Specific Resource Records
One ATM specific resource record, TYPE A for CLASS ATM, has been defined.
It is used to map from domain names to ATM addresses. ATM address lookup
operates analogously to IP address lookup: the only distinction is that the
requested class is ATM (or "*") instead of INTERNET.
In CLASS ATM, TYPE A has the following RDATA format:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| FORMAT | |
+--+--+--+--+--+--+--+--+ |
/ ADDRESS /
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
The fields have the following meaning:
FORMAT: One octet that indicates the format of ADDRESS. The two
possible values for FORMAT are value 0 indicating OSI NSAP format and
value 1 indicating E.164 format.
ADDRESS: Variable length string of octets containing the ATM address of
the node to which this RR pertains. The value is binary encoding of the
ATM address. This ATM address appears in the ATM End System
Address Octets field or the address number digits field of the Called or
Calling party number information element.
Type A RRs cause no additional section processing.
Other ATM specific resource records can be added in future releases of this
specification.
5.3. ATM Address to Domain Name Mapping
The PTR RR is defined in [RFC1035]. This RR is typically used under the "IN-
ADDR.ARPA" domain to map from IPv4 addresses to domain names.
Similarly, the PTR RR is used to map from ATM addresses to domain names
under the "ATM.INT" domain. A domain name is generated from the ATM
address according to the rules described below. A query is sent by the resolver
requesting a PTR RR for the provided domain name.
A domain name is generated from a OSI NSAP formatted ATM address by
concatenating from left to right the following substrings and separating them by a
"." character from each other:
the SEL field
the ESI field
the digits of the HO-DSP field in reverse order and separated by a "."
character from each other
the DCC, ICD, or E.164 field
the AFI field
the top level subdomain "NSAP.ATM.INT."
For example, the domain name used in the reverse lookup for the ATM address
39246f000e7c9c03120001000100001234567800
would appear as
00.000012345678.1.0.0.0.1.0.0.0.2.1.3.0.c.9.c.7.e.0.0.0.246f.39.NSAP.ATM.INT.
A domain name is generated from an E.164 formatted ATM address by
concatenating from left to right the following substrings and by separating them
with a "." character.
the digits of the national significant number in reverse order and separated
by a "." character from each other
the country code
the top level subdomain "E164.ATM.INT."
For example, the domain name used in the reverse lookup for the E.164
number
358400123456
would appear as
6.5.4.3.2.1.0.0.4.358.E164.ATM.INT.
Implementation note: For sanity's sake user interfaces should be designed to allow
users to enter ATM addresses using their natural order, that is, as they are typically
written on paper. Also, arbitrary "."s should be allowed (and ignored) on input.
5.4. Example Master File Format
This section describes an example master file format. Note that other formats are
possible.
The format of CLASS ATM RRs in Master Files conforms to Section 5,
"Master Files," of [RFC1035].
The mnemonic used to indicate the CLASS ATM is "ATM".
The RDATA section of an A line in a master file is expresses as follows:
OSI NSAP formatted ATM address: a string of hexadecimal digits. A "."
character can be used to separate any two digits for readability. The string
is case insensitive. For example:
39.246f.00.0e7c9c.0312.0001.0001.000012345678.00
E.164 formatted ATM address: a "+" character followed by a string of
decimal digits that form an international E.164 number. A "." character
can be used to separate any two digits for readability. For example:
+358.400.123456
Below are examples of the use of ATM RRs in Master Files to support name-to-
ATM address and ATM address-to-name mapping.
;;;;;;
;;;;;; Master File for domain dat.tele.fi.
;;;;;;
@ ATM SOA lohi.dat.tele.fi. jh.lohi.dat.tele.fi. (
1994041800 ; Serial - date
1800 ; Refresh - 30 minutes
300 ; Retry - 5 minutes
604800 ; Expire - 7 days
3600 ) ; Minimum - 1 hour
ATM NS lohi.dat.tele.fi.
ATM NS ns.tele.fi.
;
$ORIGIN dat.tele.fi.
salmon ATM A 39.246f.000e7c9c031200010001.000012345678.00
char ATM A 39.246f.000e7c9c031200010001.000023456789.00
;;;;;;
;;;;;; Master File for reverse mapping of ATM addresses under the
;;;;;; prefix 39.246f.000e7c9c031200010001
;;;;;;
@ ATM SOA lohi.dat.tele.fi. jh.lohi.dat.tele.fi. (
1994041800 ; Serial - date
1800 ; Refresh - 30 minutes
300 ; Retry - 5 minutes
604800 ; Expire - 7 days
3600 ) ; Minimum - 1 hour
ATM NS lohi.dat.tele.fi.
ATM NS ns.tele.fi.
;
$ORIGIN 1.0.0.0.1.0.0.0.2.1.3.0.c.9.c.7.e.0.0.0.246f.39.nsap.atm.int.
00.001234567800 ATM PTR salmon.dat.tele.fi.
00.002345678900 ATM PTR char.dat.tele.fi.
6. DNS Protocol in ATM Environment
The DNS assumes that protocol messages will be transmitted as datagrams or in a
byte stream carried by a virtual circuit. Datagrams are preferred for queries and
responses due to their lower overhead. Zone refresh activities (query type AFFR)
must use reliable virtual connections.
Since ATM networks do not support datagram services, ANS queries and
responses must be carried over ATM virtual connections established between the
clients and the servers.
6.1. Recursive Processing
By default, ANS clients, when they make queries, request recursive
processing of the query (by setting the RD bit to 1 in the header of the
query). ANS name servers must support recursion. If the server gives the
client a referral, then it can happen that the client does not have ATM
connectivity to the next server. In version 1, the servers use TCP/IP to
communicate among themselves.
6.2. Initialization
The following sections describe how a ANS client initializes an ATM
virtual connection to a ANS server and how ANS queries and responses
are carried over the virtual connection. In the first release of the ATM
name service specification, ANS servers are assumed to be running in
TCP/IP capable hosts and TCP is used for reliable communication.
6.3. Client Initialization
When a client becomes operational, initially it needs to find the ATM addresses of
one or more ANS servers. ANS clients use one of two mechanisms locate the
ATM address of ANS servers:
Get the ANS server addresses via ILMI.
Use a well-known ANS Address.
Getting ANS server addresses via ILMI is accomplished by defining a new type
value for the atmfSrvcRegTypes ILMI object that denotes ANS server:
-- ANS Server
atmfSrvcRegAnsServer OBJECT IDENTIFIER ::= { atmfSrvcRegTypes x }
If an DNS server address cannot be obtained from ILMI or if the client is unable to
establish a VC any ILMI supplied server address, then a well-known address may
be used. The well known address is
0x47007900000000000000000000.00a03e00000y.00.
<editor's note: x and y are TBD>
6.4. Connection Usage
After learning the ATM address of one or more ANS servers, an ANS client may
setup a connection to any one of the servers for sending ANS requests and
receiving ANS responses. The client sets up and releases the connection
dynamically using the UNI signaling protocol. The client should time-out after
some period of inactivity and release this connection. The server may release an
inactive connection so that the server provide services with other clients.
7. Native ATM Services Interface
The ANS client and ANS server access the ATM network via an API whose semantics are
specified by [ATMNAS]. The Native ATM Services connection attributes used for
communications between an ANS client and an ANS server are shown in the table below:
Attribute Name
Attribute Value
AAL_TYPE
AAL type 5
AAL5_FWD_MAX_SDU
512 bytes
AAL5_BAK_MAX_SDU
512 bytes
AAL5_SSCS_TYPE
Null
FWD_PCR_CLP1
line rate in cells per second
BAK_PCR_CLP1
line rate in cells per second
BEST_EFFORT
best effort requested
BEARER_CLASS
class X (BCOB-X)
TRAFFIC_TYPE
no indication
TIME_REQ
no indication
CLIPPING_IND
not susceptable to clipping
CONNECT_CONFIG
point-to-point connection
APPL_ID_TYPE
vendor-specific application ID
APPL_ID
The OUI (BHLI octets 6-8) is 0x00A03D.
The application ID (BHLI octets 9-12) is 0x00000001.
CALLED_ADDR_FORMAT
either private or public address format
CALLED_ADDR
ATM address of DNS server
CALLED_SUBADDR_TYPE
private subaddress format, if required
CALLED_SUBADDR
ATM subaddress of DNS server, if required
FWD_QOS_CLASS
QoS class 0
BAK_QOS_CLASS
QoS class 0
SSCS
Null
The following elements form a SAP address for the DNS server:
ATM address, including the selector byte
DNS application identification (carried in the BHLI information element)
Note that both layer-2 protocol identification and layer-3 protocol identification are ABSENT.
8. ATM Directory Service Interface
9. References
[ATMNAS]
ATM Forum Technical Committee, "Native ATM Services: Semantic Description,
Version 1.0", af-saa-0048-000, ATM Forum, January, 1996
[BSD4.3] S. J. Leffler, M. K. McKusick, M. Karels,
The Design and Implementation of the 4.3 BSD Unix Operating System,
1989
[DNSSEC]
D. Eastlake and C. Kaufman, "Domain Name System Protocol Security
Extensions", Internet Draft, March 1994, <draft-ietf-dnssec-secext-03.txt>.
[DNSDYN]
S. Thomson, Y. Rekhter, and J. Bound, "Dynamic Updates in the Domain Name
System (DNS)", Internet Draft, March 1995, <draft-ietf-dnsind-dynDNS-01.txt>
[DNSIZT]
M. Ohta, "Incremental Zone Transfer in DNS", August 1995, <draft-ietf-dnsind-
ixfr-03.txt>
[DNSNOT]
P. Vixie, "DNS NOTIFY, a mechanism for prompt notification of zone changes",
Internet Draft, October 1995, <draft-ietf-dnsind-notify-04.txt>
[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.
[RFC1706]
B. Manning and R. Colella, "DNS NSAP Resource Records", RFC 1706,
ISI/NIST, October 1994.
10. Appendix 1 - Example ANS API
This informative appendix contains an example API for ANS.
The interface to ANS could conform to the BSD 4.3 interface used today to resolve IP
protocol family addresses. This interface consists of the following system calls (defined
here in the most common 'C'-syntax)
extern int h_errno;
struct hostent *gethostbyname(name)
char *name;
struct hostent *gethostbyaddr(addr, len, type)
char *addr; int len, type;
struct hostent *gethostent()
sethostent(stayopen)
int stayopen;
endhostent()
herror(string)
char *string;
where
struct hostent {
char *h_name; /* official name of host */
char **h_aliases; /* alias list */
int h_addrtype; /* host address type */
int h_length; /* length of address */
char **h_addr_list; /* list of addresses from name server */
};
#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 be AF_INET always as well. The necessary new
specifications are two defines
#define AF_ATMNSAP
#define AF_ATME164
where the values are usually defined in the file socket.h and will vary among
implementations. If a mixture of IP/ATM addresses is found, the following should be
returned:
h_addrtype AF_MULTIPLE
that has to be specified in an RFC to be compatible with IETF.
The h_length is set to the length of the structures chained in h_addr_list. Each
structure in the h_addr_list looks the following way
struct
{
CHAR address[h_length-2];
WORD addresstype;
};
where addresstype is any of the address family numbers describing what type of
address is given in this structure. The address is filled into the address member starting at
the beginning. The call returning AF_MULTIPLE must put IP addresses in the front of the
list to assert comptability with implementations that assume that h_addrtype returned
is always AF_INET as it is in most implementations today a matter of fact.
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
described in [BSD4.3].
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 atmnsap_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 8.4.
11. Appendix 2 - Requirements
This informative appendix captures the SAA/DS working group's requirements.
11.1. Basing of ANS on DNS
The ANS is based on the Domain Name Service (DNS) [RFC1034],
[RFC1035] including its security [DNSSEC], dynamic update [DNSDYN],
prompt notification of zone changes [DNSNOT] and incremental zone
transfer capability [DNSIZT] extensions. There are many reasons to use
DNS as the basis for ANS.
1.1.1. DNS is widely implemented in end systems.
1.1.2. DNS domain registration procedure has been implemented in most
countries.
1.1.3. DNS domain names are well known by the user community.
1.1.4. DNS can scale well if the name space is properly assigned. This
satisfies the requirement given in 2.1.3.
1.1.5. DNS implementations are efficient in terms of CPU and memory
usage. This satisfies the requirement given in 2.1.2.
1.1.6. DNS is resilient via the secondary server mechanism. This satisfies
the requirement given in 2.1.1.
1.1.7. DNS has low latency of queries. This satisfies the requirement
given in 2.1.4.
1.1.8. DNS extensions for dynamic updates and security are being worked
on.
1.1.9. DNS can be easily augmented with new database objects for ATM.
1.1.10. DNS allows dual hosts to choose between IP and native ATM.
11.2. 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.
<editor's note: as agreed at the last meeting, the use of native
ATM services is to be based on a contribution to the Los Angeles
meeting.>
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.
ATM Forum 95-1532R2 Straw Vote 16 SAA/Directory Services ANS
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic