Internetworking Over NBMA James V. Luciani
INTERNET-DRAFT (Bay Networks)
<draft-ietf-ion-scsp-atmarp-00.txt> Barbara Fox
(Harris & Jeffries)
Expires September 1997
A Distributed ATMARP Service Using SCSP
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 ds.internic.net (US East Coast), nic.nordu.net
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
Rim).
Abstract
This document describes a method for distributing an ATMARP service
within a LIS[1]. This method uses the Server Cache Synchronization
Protocol (SCSP)[2] to synchronize the ATMARP server databases within
a LIS. When SCSP is used to synchronize the caches of ATMARP servers
in a LIS, the LIS defines the boundary of an SCSP Server Group (SG).
1. Introduction
An ATMARP Client implicitly registers (e.g., by sending an ATMARP
Request for itself; see [1]) and refreshes its own ATMARP information
with a single ATMARP server in its atm$arp-req-list table. In
addition, the ATMARP Client uses the ATMARP service to gain access to
and re-validate ATMARP information about other ATMARP Clients in its
Logical IP Subnet (LIS). Since, there MAY be multiple ATMARP servers
in a given LIS, and since any ATMARP server within the LIS MUST be
Luciani, Fox [Page 1]
INTERNET-DRAFT SCSP Expires September 1997
able to reply to ATMARP requests for ATMARP information about any
ATMARP Clients within the LIS, there MUST be a method by which to
synchronize ATMARP information across all ATMARP Servers within the
LIS. The Server Cache Synchronization Protocol (SCSP) solves the
generalized server synchronization/cache-replication problem for
distributed databases, and thus SCSP MAY be applied to the ATMARP
server database synchronization problem with the LIS. When SCSP is
used to synchronize the caches of ATMARP servers in a LIS, the LIS
defines the boundary of an SCSP Server Group (SG).
SCSP is defined in two parts: the protocol independent part and the
client/server protocol specific part. The protocol independent part
is specified in [2] whereas this document will specify the
client/server protocol specific part where ATMARP is the
client/server protocol.
2. Overview
All ATMARP servers belonging to a Logical IP Subnet (LIS)[1] are said
to belong to a Server Group (SG). An SG is identified by, not
surprisingly, its SGID which is contained in a field in all SCSP
packets. All SCSP packets contain a Protocol ID (PID) field as well.
This PID field is set to 0x0001 to signify that SCSP is synchronizing
ATMARP server databases as opposed to synchronizing some other
protocol's databases (see Section B.2.0.1 of [2] for more details).
In general, PIDs for SCSP will be assigned by IANA upon request given
that a client/server protocol specific specification has been
written. In the case of ATMARP, the client/server protocol specific
specification was initially written at the same time as SCSP, and
thus a PID=0x0001 was assigned by the author.
SCSP places no topological requirements upon an ATMARP SG.
Obviously, however, the resultant graph of ATMARP servers must span
the set of ATMARP servers to be synchronized. For more information
about the client/server protocol independent part of SCSP, the reader
is encouraged to see [2].
When an ATMARP SG is using SCSP for synchronization, a given ATMARP
Client will use only one ATMARP server and it will use that server
for remainder of its participation in the SG. This server is said to
be the "serving ATMARP server." There needs to be some hysteresis on
refreshes since every ATMARP Request may cause a cache update/refresh
in the serving ATMARP Server, and such refreshes might cause
excessive traffic if propagated to all ATMARP Servers in the SG. In
the case of mere refreshes, where no change occurs to the ATMARP
Server's cache entry for the ATMARP Client, SCSP updates will occur
at a maximum rate of once every 10+Random(2) minutes.
Luciani, Fox [Page 2]
INTERNET-DRAFT SCSP Expires September 1997
When an ATMARP client has left a server group (e.g., as the result of
a crash), it MUST NOT rejoin the SG by generating new ATMARP requests
to any other ATMARP Server than the one it previously used for a
period of time greater than 20 minutes minus the time since the last
ATMARP request was made by the ATMARP Client. This is necessary
because no mechanism exists to tell the ATMARP service that the
ATMARP Client has left the SG and because ATMARP Server table entries
are valid for 20 minutes from the time the entries are
created/updated.
3. Format of the CSA Record ATMARP Specific Part
CSA Records in SCSP contain a "Client/Server Protocol Specific Part"
which contains the non-protocol independent information for a given
server's cache entry.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hardware Type | Protocol Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| State | ATM Addr T/L |ATM SubAddr T/L| Proto Addr Len|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ATM Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ATM SubAddress (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
With the exception of the State and unused fields, these fields
contain the values specified in the ATMARP Request and Reply packets
defined in [1] which are used to create, update, and access ATMARP
server cache entries.
Hardware Type
Defines the type of "link layer" addresses being carried. This
value is the ATM Forum 'address family number' specified in [3] as
19 decimal (0x0013). This is the ar$hrd field defined in [1].
Protocol Type
This field is the protocol type number for the protocol using
ATMARP from [3]. (IP is 0x0800). This is the ar$pro field from
[1].
State
This field contains a value which represents the new state of the
Luciani, Fox [Page 3]
INTERNET-DRAFT SCSP Expires September 1997
client.
0 - New client available.
1 - Client entry has been updated.
Note that a time-out of a cache entry does not cause a CSA Record
to be sent because, if everything is working properly then all
ATMARP servers have the cache entry timing out at the same time.
Thus, the individual servers would take the appropriate actions
necessary.
ATM Addr T/L
This field contains the type and length of the ATM Address field.
The type and length encodings are described in Section 8.7.3 of
[1].
ATM SubAddr T/L
This field contains the type and length of the ATM SubAddress
field. The type and length encodings are described in Section
8.7.3 of [1].
Proto Addr Len
This field contains the length of the Protocol Address field. For
IPv4, the value is 4.
ATM Number
This is the ATM address of an address binding in an ATMARP server
cache entry. The address, if specified, is E.164 or ATM Forum
NSAPA.
ATM Subaddress
This is the ATM subaddress of an address binding in an ATMARP
server cache entry. The subaddress, if specified, is an ATM Forum
NSAPA. If null, no storage will be allocated.
Protocol Address
This is the internetwork address of an address binding in an ATMARP
server cache entry.
4. Values for SCSP Protocol Independent Part
The following sections give values for fields of the SCSP Protocol
Independent Part of the various SCSP messages.
Luciani, Fox [Page 4]
INTERNET-DRAFT SCSP Expires September 1997
4.1 Values for the SCSP "Mandatory Common Part"
Protocol ID = 0x0001
Sender ID Len = 0x04
Recvr ID Len = 0x04
See Section B.2.0.1 of [2] for a detailed description of these
fields.
4.2 Values for the SCSP "CSAS Record"
Cache Key Len = 0x04
Orig ID Len = 0x04
See Section B.2.0.2 of [2] for a detailed description of these
fields.
References
[1] "Classic IP and ARP over ATM", Mark Laubach and Joel Halpern,
draft-ion-ipatm-classic2-02.txt, March, 1997.
[2] "Server Cache Synchronization Protocol", Luciani, Armitage, Halpern,
draft-ietf-ion-scsp-01.txt.
[3] Assigned Numbers, J. Reynolds and J. Postel, RFC 1700.
Acknowledgments
I would also like to thank the members of the ION working group of
the IETF, whose review and discussion of this document has been
invaluable.
Luciani, Fox [Page 5]
INTERNET-DRAFT SCSP Expires September 1997
Author's Address
James V. Luciani
Bay Networks, Inc.
3 Federal Street, BL3-04
Billerica, MA 01821
phone: +1-508-916-4734
email: luciani@baynetworks.com
Barbara A. Fox
Harris & Jeffries
888 Washington Street
Dedham, MA 02026
phone: +1-617-329-3200
email: bfox@hjinc.com
Luciani, Fox [Page 6]
