INTERNET-DRAFT Carl Marcinik
Expires May 16, 1996 FORE Systems,Inc.
Fong Ching Liaw
Ipsilon Networks,Inc.
November 22, 1995
ATMARP Client Autoconfiguration
<draft-marcinik-ipatm-auto-arp-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 learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet- Drafts
Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Abstract
This memo describes an extension to RFC 1577 [1] that allows an
ATMARP client to automatically locate its ATMARP server. This
procedure is facilitated through the use of ATM anycast addressing
[2]. ATMARP clients use a LIS-specific anycast address to locate
their LIS-designated ATMARP Server. Both an ATMARP client and an
ATMARP server algorithmically determine their LIS-specific anycast
address upon restart. The use of this procedure will significantly
relieve the administrative burden currently required to (re)configure
a Classical IP network.
This procedure requires that an IP address and subnet mask be made
available (e.g., through manual configuration) before
autoconfiguration can be initiated for a given ATMARP client or
server. In addition, this procedure requires an ATMARP client or
server to support the capability to detect a change to its IP address
and/or subnet mask during operation. The autoconfiguration procedure
requires no changes to the packet formats specified for ATMARP and
InATMARP in [1]. This procedure is not applicable to PVCs.
While autoconfiguration is the preferred mode of operation for an
ATMARP client, all clients must support manual configuration of their
ATMARP server address. Interoperability between ATMARP servers and
clients supporting this autoconfiguration procedure and those that do
not is subject to the following constraints. An ATMARP server
utilizing this autoconfiguration procedure must be able to service
all clients in the LIS whether they support manual configuration or
autoconfiguration. Therefore, this procedure requires that an ATMARP
server accept calls to either the LIS-specific anycast address or its
individual ATM address. For the case in which a LIS is serviced by an
ATMARP server not supporting this procedure, clients are restricted
to using manual configuration only.
1. ATMARP Client Autconfiguration Procedures
In addition to the operational requirements specified for an ATMARP
client in [1], the client, upon restart, must determine the "ATMARP
Client Autoconfiguration" anycast address to use for the LIS to which
it belongs. The client accomplishes this by retrieving its IP address
and subnet mask and forming a subnet number. The resulting subnet
number is then embedded within the designated anycast address (see
ATMARP Client Autoconfiguration Anycast Address Format) and is used
as the ATMARP Request Address (atm$arp-req) by the client. The client
then contacts the ATMARP server to register its ATMARP information as
outlined in [1] using the LIS-specific anycast address to setup the
call.
If, during operation in the autoconfiguration mode, a client detects
that its subnet mask or IP address has changed, it must release its
connection (if one exists) to the ATMARP server. If the client's
subnet mask has changed, or if its IP address has changed in such a
way as to affect its LIS membership, it should discard all ARP table
entries associated with the affected LIS and determine the (new)
LIS-specific anycast address as previously outlined. Finally,
(whether or not LIS membership) has changed, the client must re-
register with its LIS-designated ATMARP server.
2. ATMARP Server Autconfiguration Procedures
In addition to the operational requirements specified for an ATMARP
server in [1], the server, upon restart, must determine the "ATMARP
Client Autoconfiguration" anycast address to use for the LIS it will
serve. This is accomplished as outlined above for an ATMARP client.
Upon determining the LIS-specific anycast address, the server
registers it with the network using the ILMI address registration
procedure [2] (see also ILMI Address Registration below). The
registration of the anycast address is in addition to (not instead
of) the registration of the server's individual ATM address. Upon
successful registration of the anycast address with the network, an
ATMARP server accepts calls/connections to either the LIS-specific
anycast address or its individual ATM address as outlined in [1].
When a call/connection is established using a LIS-specific anycast
address (or an individual ATM address for that matter), an ATMARP
server must use its individual ATM address as the "hardware" address
in any (In)ATMARP packets it exchanges with a client. The VC created
as a result of a call/connection established using the LIS-specific
anycast address may be shared and thus may also be used for non-
address resolution traffic.
If, during operation in the autconfiguration mode, a server detects
that its subnet mask has changed, or that its IP address has changed
in such a way as to affect its LIS membership, it must perform the
following actions. First, it must deregister the appropriate anycast
address from the network. The server must then release all client
connections that correspond to the affected LIS and discard their
associated ARP table entries. The ATMARP server then determines the
new LIS-specific anycast address to be used and registers this
address with the network using the ILMI address registration
procedure. Upon successful completion of address registration, the
server accepts calls/connections to either the (new) LIS-specific
anycast address or its individual ATM address.
3. ILMI Address Registration
If the autoconfiguration procedure is supported by an ATMARP server,
the ILMI address registration procedure must be used to register both
its individual ATM address and its LIS-specific anycast address with
the network as described in [2]. The occurrence of any of the events
listed below, following successful registration of these addresses,
will cause the addresses to be automatically de-registered:
o A coldStart Trap received from the network-side UME
o Detection of a "UNI Down" condition by the user-side UME
o A coldStart Trap sent by the user-side UME to the network-side
UME
In response to any of these events, the server must re-register the
LIS-specific anycast address with the network in addition to
performing ILMI address registration for the server's individual ATM
address. Once the server's LIS-specific anycast address and
individual ATM address have been successfully registered, the server
again accepts calls/connections to either address.
4. ATMARP Client Autoconfiguration Anycast Address Format
The format of the LIS-specific anycast address identifying the
"ATMARP Client Autoconfiguration" service is defined according to [2]
as follows:
C5.0079.xx.xxxxxx.xxxx.nnnnnnnn.???????00001.00
where nnnnnnnn is the 32-bit subnet number determined by the client
or server.
[Note: xx digits to be assigned by the ATM Forum]
5. Open Issues
One of the interesting issues concerning this scheme is how to manage
the dynamic relationship existing between a Classical IP LIS and P-
NNI [3] peer groups. A Classical IP LIS may overlay P-NNI peer groups
in an arbitrary way. When a LIS-specific anycast address is used to
set up a connection to the ARP server, the client must either
explicitly supply a Connection Scope Selection IE and choose the
appropriate scope for the call or use the default (Local Network)
provided by the network. However, how does one choose the appropriate
connection scope a priori? What happens when the underlying P-NNI
topology changes such that certain clients or servers are pushed
outside the scope used by other clients or servers to initially setup
connections to the affected stations? What happens when the
boundaries of the LIS change such that certain clients or servers end
up in P-NNI peer groups outside the scope of any existing calls setup
by anycast?
Perhaps one approach that might be used to address these issues would
be for the client, at initialization, to attempt to setup a call
using the LIS-specific anycast address and the lowest possible scope.
If a connection cannot be established at this scope, try the next
highest scope, and so on. Once a connection has been established, the
client should record the scope at which the connection was
successful. If for any reason, the client's connection would be
released, it could first try to re-establish the connection using the
scope that was previously successful. This topic requries further
consideration.
6. References
[1] Laubach, M., "Classical IP and ARP over ATM", RFC 1577,
Hewlett-Packard Laboratories, January 1994.
[2] ATM Forum, "ATM User-Network Interface (UNI) Signalling
Specification Version 4.0", ATM Forum, December 1995.
[3] ATM Forum, "PNNI Draft Specification", 94-0471R12,
ATM Forum
7. Security Considerations
Security issues are not addressed in this memo.
8. Acknowledgments
The authors would like thank Drew Perkins (FORE Systems) for useful
feedback on earlier versions of this proposal.
9. Authors' Addresses
Carl Marcinik
FORE Systems, Inc.
Pittsburgh Office and Research Park
5800 Corporate Drive
Pittsburgh, PA 15237-5829
Phone: (412) 635-3338
EMail: carlm@fore.com
Fong Ching Liaw
Ipsilon Networks, Inc.
2191 E. Bayshore Road, Suite 100
Palo Alto, CA 94303
Phone: (415) 846-4600
EMail: fong@ipsilon.com