home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1997 December
/
Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso
/
drafts
/
draft_ietf_i
/
draft-ietf-ion-discov-atmarp-00.txt
< prev
next >
Wrap
Text File
|
1997-08-21
|
10KB
|
358 lines
Internet-Draft Mike Davison
Cisco Systems
August 21, 1997
ILMI-Based Server Discovery for ATMARP
<draft-ietf-ion-discov-atmarp-00.txt>
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."
To view the entire list of current Internet-Drafts, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Abstract
This memo defines how ILMI-based Server Discovery, which provides a
method for ATM-attached hosts and routers to dynamically determine
the ATM address of servers, shall be used to locate ATMARP servers.
Davison Expires February 21, 1998 [Page 1]
Internet Draft August 21, 1997
1. Introduction
Presently, configuring a host or router to use ATMARP [1,2] is
cumbersome and error-prone since it requires at least one ATM
addresses to be statically configured on each host or router in the
network. Further, it is impossible to implement a diskless host to
use ATMARP since local configuration is required. ILMI-based Server
Discovery, hereafter referred to as "server discovery," provides a
solution to these problems.
A brief overview of the Service Registry MIB, as defined by the ATM
Forum, is provided in this memo. The reader should consult [3] for a
complete description of this MIB, but the information contained here
is sufficient for an understanding of its use to support ATMARP
server discovery.
2. ILMI 4.0 Service Registry MIB
Server discovery utilizes the Service Registry MIB defined by the ATM
Forum in ILMI Specification Version 4.0 [3]. To support the existing
framework for IP over ATM, ATM switches must support the Service
Registry MIB.
A row in the service registry table [3] is defined as:
AtmfSrvcRegEntry ::= SEQUENCE {
atmfSrvcRegPort INTEGER,
atmfSrvcRegServiceID OBJECT IDENTIFIER,
atmfSrvcRegATMAddress AtmAddress,
atmfSrvcRegAddressIndex INTEGER,
atmfSrvcRegParm1 OCTET STRING
}
The definition of each field in this structure is:
atmfSrvcRegPort - The port number for which this entry contains
management information. The value of zero may be used to
indicate the ATM interface over which a management request
was received.
atmfSrvcRegServiceID - This is the service identifier which
uniquely identifies the type of service at the address
provided in the table. (See Appendix for ATMARP OID.)
atmfSrvcRegATMAddress - This is the full address of the service.
Davison Expires February 21, 1998 [Page 2]
Internet Draft August 21, 1997
The ATM client will use this address to establish a connection
with the service.
atmfSrvcRegAddressIndex - An arbitrary integer to differentiate
multiple rows containing different ATM addresses for the same
service on the same port.
atmfSrvcRegParm1 - An octet string whose size and meaning is
determined by the value of atmfSrvcRegServiceID.
The service registry table is indexed by atmfSrvcRegPort,
atmfSrvcRegServiceID and atmfSrvcRegAddressIndex.
3. Service Parameter String
A generic parameter string is defined in the service registry table,
thus allowing protocol-specific parameters to be specified. To be
consistent with [1,2], the parameter string for ATMARP shall be:
ar$pro 16 bits Protocol type
ar$plen 8 bits Length of protocol address (a)
ar$addr a octets Network address
ar$mask a octets Network mask
Where
ar$pro - see Assigned Numbers for protocol type number for
protocol using ATMARP. (IPv4 is 0x0800, IPv6 is 0x86DD)
ar$plen - Length of the protocol address. (IPv4 is 4, IPv6 is 16)
ar$addr - Network address represented in network byte order
ar$mask - Network mask represented in network byte order
4. ATMARP Client Behavior
An ATMARP client will access the service registry table via ILMI
using the SNMP GetNext operator to "sweep" (SNMP parlance for a
linear search) beginning with {Port = 0, ServiceID = <see Appendix>,
Index = 0} while holding the port number and the serviceID constant.
(Port number 0 is used within ILMI to indicate "this port.")
An ATMARP client with no local configuration, such as a diskless
Davison Expires February 21, 1998 [Page 3]
Internet Draft August 21, 1997
workstation, must use the row with the lowest index value if multiple
ATMARP servers, possibly for multiple networks, are listed.
ATMARP clients that have local IP configuration must use a row that
has the appropriate IP address. For example, consider the case where
an IP router has 3 logical interfaces defined on a single physical
interface with IP addresses 1.0.0.1/8, 128.10.0.1/16 and
171.69.150.226/24. The router will sweep the service registry table
looking for a rows that have atmfSrvcRegParm1 values as shown below:
Network number/mask atmfSrvcRegParm1
-------------------- --------------------------------------
1.0.0.0/8 08 00 04 01 00 00 00 ff 00 00 00
128.10.0.0/16 08 00 04 80 0a 00 00 ff ff 00 00
171.69.150.0/24 08 00 04 ab 45 96 00 ff ff ff 00
When the correct atmfSrvcRegParm1 values are located, the router may
then establish an SVC to the selected server and perform the
appropriate protocol operations.
Redundant ATMARP servers are supported with multiple rows in the
service registry table. This list of ATMARP servers is ordered with
the primary ATMARP server having the lowest index value. The ATMARP
client must attempt to utilize the primary ATMARP server before
utilizing a secondary ATMARP server. Administrators must ensure that
the listed ATMARP servers are synchronized via [4].
5. ATMARP Server Behavior
An ATMARP server shall be locally configured. The ATMARP server may
retrieve the ATMARP service registry data to validate the results. If
an incorrect row is retrieved the error may be flagged in a locally
significant way.
6. Relationship with PNNI Augmented Routing
An augmented version PNNI ("PNNI Augmented Routing," or PAR) [5] is
being developed by the ATM Forum. PAR could potentially distribute
data such as ATMARP server addresses. Further, the ATM Forum is
developing a proxy mechanism for PAR (Proxy PAR) [6] that would allow
a UNI-attached host or router to access PAR data without a full PAR
implementation.
These mechanisms offer a promising way to manage the service registry
Davison Expires February 21, 1998 [Page 4]
Internet Draft August 21, 1997
tables maintained on each switch in an ATM network, yet would not
require changes to the mechanism defined in this memo. Hosts and
routers can continue to utilize ILMI-based or Proxy PAR-based server
discovery and network administrators could manage the service
registry data with local configuration or via PAR and Proxy PAR.
7. Security Considerations
The server discovery mechanism is intended for environments where a
given ATM switch and its attached hosts or routers are in the same
administrative domain, hence no authentication is required.
Appendix - ATMARP Server Discovery MIB
SERVER-DISCOVERY-ATMARP DEFINITIONS ::= BEGIN
--
-- This OID names ATMARP within the context of server discovery.
-- It does not name any managed objects.
--
serverDiscoveryATMARP OBJECT IDENTIFIER ::= <TBD>
END
References
[1] Laubach, M., "Classical IP and ARP over ATM," RFC 1577,
Hewlett-Packard Laboratories, December 1993.
[2] Laubach, M. Halpern, J., "Classical IP and ARP over ATM,"
draft-ietf-ion-classic2-02.txt, (update to RFC 1577), March 1997.
[3] ATM Forum, "Integrated Local Management Interface (ILMI)
Specification Version 4.0," af-ilmi-0065.000, September, 1996.
[4] Luciani, J., and Fox, B., "A distributed ATMARP Service Using
SCSP," <draft-ietf-ion-scsp-atmarp-00.txt>, April, 1997.
[5] Callon, R., et al., "An Overview of PNNI Augmented Routing,"
ATM-Forum 96-0354, April, 1996.
Davison Expires February 21, 1998 [Page 5]
Internet Draft August 21, 1997
[6] Przygienda, T., and Droz, P., "Proxy PAR," ATM-Forum 97-0495,
July, 1997.
Author's Address
Mike Davison
Cisco Systems
170 West Tasman Drive
San Jose, California 95134
Phone: (408) 526-4000
EMail: mike.davison@cisco.com
Davison Expires February 21, 1998 [Page 6]